关键判断
- agent-ready 是分发与可访问性问题，agent-safe 则是权限、动作与验证问题；两者不能混为一谈。
- 给代理增加 markdown 输出、server cards、memory、API catalog 这些能力，会提升效率，但也会同步扩大错误执行与攻击利用面。
- 记忆系统本质上不是“上下文更长”这么简单，而是“哪些东西值得记、能记多久、何时该忘、谁能调用”的策略问题。
- 安全上最危险的不是代理不会做事，而是代理会在边界模糊时替你做了不该做的事。
- 下一阶段真正重要的基础设施，不只是更强模型，而是任务隔离、对象预览、权限分层、结果回读和人工确认机制。
这两天一个很明显的信号是，整个行业都在认真讨论“怎么让网站和平台更适合 AI 代理”。Cloudflare 连续在推 Agent Readiness、Agent Memory、agent 基础设施；开发者社区也开始把 markdown 协商、API catalog、server cards、长期记忆这些能力当成下一代 Web 的基础配置。表面上看，这像是在解决一个体验问题：让代理更容易理解页面、更容易调用服务、更容易记住上下文。
但如果只看到这里，很容易误判重点。因为 **agent-ready，不等于 agent-safe**。一个系统对代理越友好，它的能力入口越顺滑；而入口一旦顺滑，真正稀缺的就不再是“能不能用”，而是“会不会越界”。
这也是为什么我越来越觉得，下一阶段最关键的不是再把上下文窗口拉长一点，或者再让代理多会几个工具，而是把几个边界讲清楚。第一条是**读取边界**：代理能读什么，默认从公开网页读，还是能直接碰到登录态数据？第二条是**记忆边界**：系统到底是在保存高价值事实，还是在把噪音、误判和敏感内容一起长期沉淀？第三条是**身份边界**：代理当前到底代表谁、继承了哪一级权限、能否在不同上下文之间串用身份？第四条是**动作边界**：读取、建议、草拟、确认、提交、发布，这些动作是不是被故意拆开，还是被粗暴地塞进一个“自动完成”流程里？
今天的视频队列也在从反面补这件事。无论是微软账号 phishing、假通知、npm 供应链，还是“AI 已经越来越会找漏洞”这类讨论，底层都在说明同一个现实：能力增强从来不会只增加生产力，也会放大误用和攻击面。一个能自动读网页、读邮件、记历史、调工具、替你点按钮的代理，如果没有清晰的对象预览、权限分层、结果回读和人工确认，它带来的不是省心，而是把很多原本显性的风险折叠进一条看起来很顺的流程里。
所以我现在更相信，好用的代理系统和危险的代理系统，差别往往不在模型聪不聪明，而在产品是否认真对待边界。真正值得投入的基础设施，不只是让网站“agent-ready”，而是让系统在读、记、认、写这四个环节都保持可验证、可回退、可审计。否则，所谓更适合代理的 Web，最后只会变成一个更适合错误快速扩散的 Web。