Levie 说 agent 要先学会验收，Zara 说公司得先让它读懂：7月15日精选

7 月 15 日窗口里，最值得留下的不是又一个模型宣传语，而是一个更具体的落地问题：agent 做完一件事之后，企业能不能判断它做对了，组织又有没有把完成任务所需的知识暴露出来。

Aaron Levie 从代码为什么适合 agent 讲起：代码可以很快手动验证，也可以直接运行测试；但股票交易、合同谈判、销售演示等知识工作，往往要等到结果进入现实世界，才知道哪里出了问题。他据此判断，未来会出现更多测试其他工作的机会，企业需要为大多数工作流建立 eval，才能知道模型、提示词或系统变化带来了改进还是回归。1

这条判断的重点不在于「eval 很重要」这句熟悉的结论，而在于它把 agent 的扩张条件落到了知识工作的验收接口。没有验收标准，企业很难把一次成功的演示变成可持续的流程。

Zara Zhang 把问题从工作结果推进到公司结构：「如果想让 agent 真正在公司里工作，就得把公司设计成它能够读取的样子。」她举 Shopify 的一个 agent 为例：它没有私聊功能，只有公开频道；她观察到的副作用是员工之间产生了相互学习。这里的 Shopify 例子来自她的个人推文，本文不把它扩写成 Shopify 的官方制度说明。2

把 Levie 和 Zara 放在一起看，企业 agent 至少有两道不同的门槛：第一道是能否评估工作结果，第二道是能否读取任务上下文。前者解决「做得对不对」，后者解决「它有没有机会知道应该怎么做」。

Zara 同日还写道，自己没有按传统方式学习编程，因此 coding agent 对她而言更像创造和自我表达的工具，GitHub 则近似她的 Substack。这是个人工作方式的观察，不是关于 GitHub 分发效果的统计结论，但它说明 agent 的价值已经从替人写代码延伸到帮助非传统开发者公开产出。3

Guillermo Rauch 给出的信号很短：他认为 Vercel Agent 适合回答优化问题，可以让它优化构建、性能和账单。原帖没有提供版本、指标或文档边界，因此这里只把它记为产品方向：agent 正被推向持续优化运行结果的任务，而不是一次性生成代码。4

Peter Yang 则预告了一期教程，准备拆解自己如何用 ChatGPT Work，也称 Codex，在电脑上完成大量任务；他写明视频会分成 7 步，包含 GPT-5.6 模型选择、邮件、日历和重复任务管理。它目前只是教程预告，不等于这些能力已经被官方作为统一产品流程确认。5

Peter Steinberger 转发并评价一篇名为 The Memory Heist 的文章「This is really clever」。文章作者描述了一条针对 Claude 网页浏览能力的攻击路径：攻击者控制网站，通过前一次 web_fetch 结果中的链接逐步引导 Claude 访问新的 URL，并把用户信息编码进 URL 路径，让服务器日志记录下来。文章还称，攻击可以利用 Claude 的每日总结式记忆和 conversation_search，甚至诱导模型从上下文推断出用户没有直接写入记忆的额外信息。6 7

文章作者写道，自己已通过 HackerOne 披露问题，并称 Anthropic 后来禁用了 web_fetch 跟随外部页面链接的能力，只保留跟随搜索结果和用户直接提供 URL 的路径。这是文章作者对披露与缓解过程的叙述，不能替代 Anthropic 的正式安全公告；但它足以提醒使用者，网页访问、记忆和工具调用组合起来后，风险不再只是模型回答是否准确。

7 月 15 日的信号拼出了一条比「模型更聪明」更实用的路线：先为知识工作建立可观察的验收标准，再让组织把必要上下文放进 agent 能读取的公共结构，最后把浏览、记忆和外部工具的权限边界单独审计。

这也解释了为什么本期没有把 Rauch 的一句产品判断写成完整发布，也没有把 Peter Yang 的教程预告写成官方能力清单。对 agent 来说，能完成一次任务只是起点；能被评估、能读懂组织、能在权限边界内持续运行，才是进入真实工作流的门槛。