这期从一次和 AI coding 创业公司的对谈开始：为什么 SWE-bench 上 O1 的实测成绩只有 Sonnet 3.5 的一半左右， 而官方文档里的数字高得多。答案不在模型，在它前面有没有那一层意图分解。顺着这条线， 这期还过了 Anthropic 那篇《Building Effective Agents》的五种工作流范式、Claude Code 的采样循环， 以及一个当时还很少被提的概念——ACI。
起点是一次对谈。Anthropic 的 CVC 和自己的投资人成立了一支企业生态基金，第一批投的公司里有一家做 AI coding， 三位联创里有一位华人。聊下来最核心的一个疑惑是：O1 官方宣布的跑分（含 SWE-bench）不低， 为什么大家把 coding agent 里的 4o 或 Sonnet 3.5 换成 O1 之后，效果反而明显变差？
他们自己实测的结果是，SWE-bench 上 O1 解决的 issue 数大约只有 Sonnet 3.5 的一半， 而 O1 官方 doc 里的数字要高得多。差别不在模型本身，在于前面有没有一层框架做意图分解—— 相当于一个 connector，有没有做这一层，结果完全不同。
更根本的原因是任务性质不一样。O1 擅长的是所有信息都已经在手上、只需要靠思考完成的任务， 最典型的就是 LeetCode 题。但解决一个 GitHub issue 要先收集上下文、要主动去问、要拿到完整信息才动手—— 直接把 O1 扔过去就不行。
顺着这个思路，当时把问题分成了三类：自己思考就能解决的、 通过逻辑或反思能解决的、以及必须反问对方才能拿到关键信息的。 第三类里往往藏着核心业务逻辑，而那正是纯推理模型最吃亏的地方。
用 Sonnet 3.5 或 4o 的时候更像做陶艺——它会跟你不停迭代，缺什么会主动问你。O1 不是这个路子。 给它的 prompt 最终形态得包含：goals、return format、warnings、以及一大段 context dump—— 你要把尝试过但没成功的一切都解释清楚，把数据库、框架、背景全都交代到位。
还有一层麻烦：「我该推理多少」这件事，O1 自己也要推理。 这就带来方差，没办法精准映射到某个任务的实现上。
这期最实用的一条判断：O1 在企业级场景里有可能根本用不了。 因为它对结果负责，不对过程负责。想改中间过程，只能回过头把前面的 prompt 全划掉重来。 真跟它对话几百个 task 之后会非常痛苦——你没法 fix，它是端到端的，最好一次命中。
所以它适合的是你愿意为结果负责、把它当新员工用的场景，比如金融分析师那类岗位； 而给企业构建 agent 时要的是过程监督、每一步都能 monitoring——这两个范式不是一回事。
再往前推一步：O1 本质上非常像一个被打包好、且不让你定制的 coding agent。 当时的普遍预期是它会成为「下一个 Cursor」——一个没有编码界面的 Cursor。但也有反问： 如果现有的 coding agent 解决问题比 O1、O3 还好，为什么要走 O1 这条路径？
接着过了 Anthropic 那篇《Building Effective Agents》。它先讲何时、如何使用框架—— 并且直言常见的那些框架（LangGraph 之类）其实没那么必要；然后给出几种工作流范式， 每种都配了适用场景：
Prompt chaining——把长任务拆开，比如生成大篇文章或小说时先做章节划分，
每章独立完成，否则整个时间会拉得非常长。
Routing——先做一次路由，把不同的事扔给不同的模型或链路。
Voting / self-consistency——多路投票再合成一个输出。这个当时很少见到真实用例，
文章举的是代码审查查漏洞、内容审核那类需要平衡漏报的场景。
Orchestrator-workers——在路由外面再加一层编排，多条路径回来后由一个 successor 做内容合成，
开源情报分析这类任务很合适。
Evaluator-optimizer——针对多文件复杂修改这类任务，coding agent 是典型代表。
整个流程里最核心的是两个 loop：clarify 需求和干活。 需求澄清完了才把任务扔给模型去 environment 里执行——搜文件、返回结果、写代码、看状态、测试、再找文件， 循环到达成 result 才 complete 并展示给用户。
这是当时一个很实际的读源码技巧：用免费的 Copilot 去解释你想读懂的那个文件， 比自己硬啃快得多。
文章里提出 ACI（Agent-Computer Interface）——你应该像投入人机界面（HCI）设计那样， 投入同等程度的努力去设计 agent 和系统之间的界面。核心诉求很朴素： 别让 agent 把时间花在那些非常机械的活上。
当时的判断是，ACI 尤其对企业端可能是个机会：那会儿大家的做法都很简单粗暴，基本只放一个 LUI， 专门为「和 agent 打交道」设计的企业界面产品几乎没有，国内更是空白。 提到的一个近似样本是把企业内的 CRM、HR 等各种系统统一转换成大模型好调用的一套接口那类产品。
Vellum 的这份报告里几个当时值得记的读数：研究自动化和合规自动化上榜； 模态分布上图像与文本类最高，但音频已经有 27%（当时的疑问是这些音频到底怎么处理的， 如果都是 ASR 转文本再当文本处理，那不太说得通）。
工程实践这边的数字更能说明当时的成熟度：一半以上的人没有在用微调， 只有约 60% 在用向量库——这个结果和 LangChain 自己那份调查差不太多。
报告里有一条当时没太读懂的结论：分析和查询这类程序性任务（procedural task）可能从 O1 中受益最多。 这和前面讨论的方向不完全一致——研究自动化、合规自动化恰恰是对错误容忍度最低的领域。
Together AI 的一位工程师根据 Anthropic 那篇文章做了 Agent Recipes—— 把长篇的 agent 开发范式变成 cookbook 式的条目，每一条都能直接看到代码。 代码本身写得比较简单，大部分也能在 Anthropic 的 cookbook 里找到，但形态对工程同学非常友好，当时是强烈推荐的。
这期最后还提到 AWS 的 Explainer——一个把知识库问答直接嵌进网页文档的产品形态。 当时的想法是：如果能把企业内部知识库融进各种文档页面里，而不是单独做成一个 chatbot， 会是比 chatbot 更友好、更直观的形态。