我的核心判断： LLM 系统的成熟，不是把所有任务都做成自主 Agent，而是能判断复杂度该停在哪一层。先把单次 LLM 调用、检索和上下文做好；不够时上 Workflow；只有任务路径无法预定义、必须边执行边观察时，才值得上 Agent。
这篇文章读下来，最打动我的不是 Anthropic 又总结了几个 Agent 模式，而是它很克制地回答了一个更基础的问题：我们到底什么时候该上 Agent？
过去一年，“Agent”很容易被讲成一种终点形态：越自主、越多工具、越长链路，就越先进。但 Anthropic 这篇工程实践的主线恰好相反：有效系统通常不是最复杂的系统，而是最适合任务的系统。复杂度不是荣誉章，它是一笔需要被性能收益证明的成本。
一、Agent 不是一个单点能力，而是一条复杂度阶梯
文章里有一个很重要的区分：Anthropic 把 Workflow 和 Agent 都放在 Agentic Systems 下面，但它们不是同一件事。
Workflow 是预定义路径里的编排。LLM 与工具被代码组织起来，输入来了以后沿着相对固定的步骤走。它的价值是可预测、一致、容易调试。
Agent 是模型在循环里动态决定下一步。它会根据环境反馈继续规划、调用工具、观察结果，并在必要时回到人那里确认。
这个区分解决了一个常见误会：我们平时说“做 Agent”，其实可能只是在做一个更结构化的 Workflow。它也许已经足够好，甚至比一个开放式 Agent 更适合生产。
我划下了 “Workflow 适用于定义良好的任务，提供可预测性与一致性” 这句话，因为它很像我在业务系统里反复遇到的工程现实：很多场景缺的不是更高的自主性，而是一条更稳定、更可排查、更可评估的路径。Agentic 不等于 autonomous，能被清楚拆解的任务，先别急着交给 Agent 自由发挥。
二、什么时候停在 Workflow，而不是继续推到 Agent
如果一个任务可以被拆成清楚的步骤，或者输入类别本身就很明确，那 Workflow 通常是更好的答案。它可以把 LLM 的不确定性放进一个更可控的结构里。
模式 核心动作 我会在什么时候用 Prompt Chaining 把大任务拆成一串更小的 LLM 调用，中间加 gate 校验。 写作、翻译、生成报告、先出大纲再扩写这类线性任务。 Routing 先分类，再把不同输入交给不同 prompt、模型或工具。 客服、工单、内容审核、简单问题用便宜模型、困难问题用强模型。 Parallelization 并行处理多个维度，或多次尝试后投票汇总。 安全审计、多维评测、护栏检查，以及需要提高置信度的判断。 Evaluator-Optimizer 一个模型生成，另一个模型评价反馈，循环改进。 有明确评估标准、且迭代能明显改善结果的任务。 这些模式的共同点是：系统设计者仍然掌握主路径。LLM 可以承担局部判断、生成和评估，但它不是完全自由地决定系统拓扑。
我的判断： 只要任务还能被表达成“先 A，再 B；如果是 X 就走 Y；多个维度并行检查；生成后再评估”，就应该优先考虑 Workflow，而不是急着上开放式 Agent。
三、放回我的工作：主链路是 Workflow，长尾才需要 Agent
读这篇时，我很自然会想到最近做的 POI / 品牌相关场景。很多所谓 Agent Demo 拆开以后，其实就是一张流程图：用户请求进来，按固定顺序调 OCR、召回、规则、模型校验、落库。它看起来有 LLM、有工具调用、有多步链路，但系统拓扑是确定的，本质上更像 Workflow。
层级 更适合放什么 为什么 主链路 Workflow OCR → 品牌候选召回 → 规则过滤 → VLM 判断 → 结果落库。 路径已知、吞吐要求高、要能 debug、要能解释每一步为什么这么判。 长尾 Agent 分析一个品牌为什么挂错、跨系统查证据链、调查一家企业、给出坏例归因。 目标明确但路径未知，需要边查边决定下一步，看什么信息、调什么工具、什么时候停。 人审与护栏 低置信、高风险、影响面大的判断，以及 Agent 需要业务判断时的确认点。 业务系统追求稳定，Agent 追求灵活，两者之间需要明确边界。 我现在更倾向的系统形态： 企业场景大概率不是 100% Agent，而是 90% Workflow + 10% Agent。Workflow 扛主链路、高频和可解释性；Agent 去处理开放探索、不确定决策和长尾 case。
这也是为什么这篇文章没有给我一种“Agent 没有想象中革命”的失落感，反而让我觉得：大家终于开始认真讨论怎么把 LLM 当工程系统用了。真正的问题不是让模型看起来最聪明，而是系统能不能稳定上线、出 case 能不能排查、成本和 SLA 能不能算清楚。
四、Agent 的价值来自真实反馈，不来自长链路本身
文章对 Agent 的描述有一个关键点：Agent 在每一步都要从环境中获得 ground truth。这里的 ground truth 不是模型自我感觉良好，而是工具返回、代码执行、测试结果、搜索结果、外部系统状态。
没有这种反馈，Agent 只是把一次幻觉拆成很多次幻觉。有了反馈，它才有机会在循环里修正路线。
- 编码 Agent 可以通过测试失败知道自己还没修好。
- 搜索 Agent 可以根据检索结果判断是否需要换查询或继续深挖。
- 客户支持 Agent 可以根据订单、工单、退款状态决定下一步动作。
所以 Agent 的本质不是“多轮”，而是“行动后能观察到可靠环境反馈”。这也是为什么编码和客户支持会成为比较自然的 Agent 场景：它们都有清晰的动作空间、外部状态和成功标准。
风险提醒： Agent 的自主性会带来更高成本、更高延迟和错误累积。生产环境里必须有沙箱、停止条件、检查点、人类确认，以及足够窄的工具权限。
五、真正被低估的是 ACI：Agent-Computer Interface
附录里关于工具设计的部分，我觉得甚至比几种 workflow 模式更值得反复读。作者说，工具定义和规范应该像整体 prompt 一样投入 prompt engineering。
原因很简单：对人类工程师来说等价的接口，对模型来说难度可能完全不同。比如修改文件，可以要求模型写 diff，也可以允许它重写完整文件；结构化输出可以放在 JSON 里，也可以放在 Markdown 里。工程上这些可能都能互转，但对 LLM 来说，哪种形式更自然、更少格式开销，差异会非常大。
贴近模型熟悉的形式： 让接口像自然文本和常见代码那样可读，少用反直觉格式。
减少格式开销： 不要让模型花大量 token 处理转义、计数、对齐和脆弱 schema。
让错误更难发生： 用参数名、示例、边界说明和防错设计塑造模型行为。
这让我想到：如果说 HCI 是为人设计软件，那么 ACI 就是为 Agent 设计软件。未来很多 Agent 体验的差距，不一定来自模型本身，而来自工具接口有没有真正站在模型视角设计。
六、我的个人结论：把 Agent 当升级选项，而不是默认架构
结合原文和自己的工作语境，我现在会把这篇文章理解成一套“复杂度升级检查表”：
- 先问最简单方案是否足够。 单次 LLM 调用、检索、上下文示例和清晰 prompt，往往已经能解决一大批问题。
- 再问任务是否能被固定拆解。 如果能，就用 Workflow，把主链路设计得透明、稳定、可观测，而不是把流程图塞进 prompt 里假装 Agent。
- 最后才问是否需要 Agent。 只有当目标明确但路径未知、需要模型根据环境反馈动态决策时，Agent 才真正成立。
一句话总结： 能用 Workflow 的地方，先别上 Agent。Agent 的价值不在“看起来会自主规划”，而在它能处理 Workflow 覆盖不了的开放探索和长尾不确定性。
这也是我读完以后最想带走的实践原则：先做小，做透明，做可测；让 Workflow 承担稳定主链路，让 Agent 只在复杂度确实能换来结果改善时登场。
延伸阅读
- Building effective agents — Anthropic Engineering
注：本文由我基于阅读笔记整理，并使用 AI 辅助润色。
