Agent 最近这一年 系列一
什么是 Agent？
在 2024 年 12 月 19 日，Anthropic 发布的 Agent 指南中给出了详细的定义，将多种智能体的实现实现统称为 agentic systems，并在架构上区分 workflows 与 agents。文档强调由模型动态主导流程与工具使用、可在环境反馈中循环推进任务，必要时在检查点征求人类反馈。
增强型 LLM 是组件，Agent 往往在此基础上加入基于环境反馈的循环、规划与决策，形成可自主推进的系统。
当时 Anthropic 指出了 Agent 和 Workflow 的区别：
- 工作流：通过预定义的代码路径编排大语言模型（LLM）与工具的系统。
- 智能体：由大语言模型动态主导自身流程和工具使用方式，并自主掌控任务完成过程的系统。
工作流能够为定义明确的任务提供可预测性和一致性，而 Agent 呢，不再是 if-else，而是模型为了完成任务参与了多次的决策与行动，动态主导自身流程和工具调用的系统，能够自主掌控任务的执行方式。
对多数应用，先用单次 LLM + 检索/示例即可，确有需求再提升为 workflows/agents。
工作流：通过不同的提示词把任务拆解成一系列的任务。
使用场景：生成营销文案后，将其翻译成其他语言。或者先撰写文档提纲，然后根据提纲完成全文写作。
路由工作流，用于对输入进行分类，并将其分派至对应的专门任务。
使用场景：客户服务请求（如一般咨询、退款申请、技术支持）分别引导到不同的下游流程、提示词和工具。
并行包含两类：Sectioning（将独立子问题并行处理）与 Voting（同一任务多次尝试以多样化/更高置信度）
使用场景：从多角度或多次尝试中获得更高置信度的结果，或者是让一个模型实例负责处理用户查询，另一个模型实例专门筛查不当内容或请求，最后整合内容输出。
在这些 workflow 的基础上还可以演变出很多：
- 任务编排：大语言模型会动态拆解任务，将子任务分派给工作者大语言模型，并整合其结果。譬如金融行业的信息审核，需对多个来源收集并分析信息，以筛选出可能相关内容的搜索任务。
- 迭代循环：文学翻译、复杂的搜索任务等等
那么 Agent 呢？
Agent 概括起来主要是四点，模型能力、任务启动、过程反馈、可在检查点征询人类反馈/判断。 模型能力要足够强，太多的幻觉肯定不行。Agent 可由用户命令/对话启动；在系统集成中也常作为上游流程的一个阶段被触发。执行过程需要工具、代码、检查点等获得反馈。终止条件可以通过譬如最大迭代次数来设置等。
这是 Agent 和 workflow 的本质区别： 智能体适用于无法预判所需步骤、也无法硬编码固定流程的开放性问题。大语言模型（LLM）可能需要多轮执行，你必须对其决策过程具备一定信任。智能体的自主性使其在可信环境中非常适合用于任务扩展。
所以最终我们通过评估输出结果，来判断 Agent 的效果。当然很多时候也需要注意，只有在简单方案无法满足需求时，才逐步引入多步智能体系统。
这是设计 Agent 的三个原则：
- 保持智能体设计的简洁。
- 优先确保透明性，明确展示智能体的规划步骤。
- 通过完善的工具文档与充分测试，精心打造智能体–计算机接口（ACI）。
2024 年，Anthropic 告诉我们智能体在需要同时具备对话与执行能力、拥有明确的成功标准、可以形成反馈闭环并融入有效人工监督的任务中，能够发挥最大的作用。客服与编程是两个尤为有前景的应用领域
以下为个人使用体验，与 Anthropic 原文无直接对应；为避免混淆，可显式标注为个人观点，不代表原文结论。
2026 年的今天来看 Anthropic 这篇文章，依然醍醐灌顶。可能是我自己常用的产品中大部分都是翻译、写作为主的方向，所以 Agent 需求并不是很大，本质上来我更需要的是一个更聪慧的模型，譬如当时 GPT-4.5的出现，以及 2025 年下半年 GPT 5.1,5.2 和 Gemini3pro 的到来。 即便在最新模型上，对于我关注的编程和健康上，虽然最新模型 GPT 更偏稳重和全面，而 Gemini 则相对激进，但在当时对于 Agent 的诉求其实并不高。
多智能体研究系统
再继续看看 Anthropic 2025 年 6 月 13 日发表的 如何打造多智能体研究系统，展示了其多智能体（multi-agent）Research 架构：由多个 Claude 智能体协作，跨 Web、Google Workspace 与各类集成工具完成复杂研究任务。
写在开始之前
对于研究系统实际有很多问题需要关注，比如：
- 究竟应该如何通过“编排者-工作者”模式，利用多个子智能体并行工作？
- 如何通过更多 Token 和工具调用来换取更高的任务成功率？
- 如何通过引导主智能体动态分配任务并利用思考模式进行自我评估与修正？
- 采用结果导向的 LLM 自动评判机制是否是唯一选择？
- 如何将不稳定的 AI 行为转化为可靠的软件服务。
开放性问题难以 if-else 硬编码，路径依赖、动态调整
很多工作因为设计开放性问题，往往很难准确预测每一步，那么也就无法通过 if-else 硬编码来实现。解决问题路上有太多的动态和路径依赖性，会依据新的发现调整方法，顺着线索持续推进。
在 Anthropic 内部评测样例中，多智能体系统将任务分解给子智能体，能找到‘S&P 500 信息技术板块公司’的董事成员，而单智能体在该样例中因顺序搜索缓慢而失败。此为特定评测场景结论，并非普遍规律。
多智能体系统表现突出有：
- 高度并行化的高价值任务-
- 信息量超出单一上下文窗口的任务
- 以及需要对接众多复杂工具的场景。 当然也有缺点，主要是成本与限制包括：Token/成本显著上升（多智能体≈对话15×）、对共享上下文/强依赖任务（如大量编码协作）不适配、实时协调与委派尚不成熟、需确保任务价值覆盖成本。
Multi-agent Architecture overview for Research：
1）LeadResearcher 将研究计划持久化到 Memory（上下文>200k会截断）； 2）研究结束进入 CitationAgent，为报告定位具体引文，确保“论断-来源”可核对。
用户查询首先经过主智能体，由其创建多个专门的子智能体并行检索不同维度的信息。
这时又不得不说下 Agent 这个搜索场景和传统 RAG 的区别：
RAG 通常采用静态检索，提取相似的一组文本片段，并用这些片段生成回复。 Multi Agent 采用多步搜索，包含发现-评估-迭代，非一次性召回；强调动态适配与分析。
- 像智能体一样思考。要迭代提示词，必须理解其实际效果。
- 教会编排器如何分派任务。本质是给它一套项目经理手册，让它学会不仅要下达指令，更要定义边界、格式和差异化路径。
- 按复杂度配置子智能体与调用预算（简单：1 agent/3–10 次；比较：2–4/10–15 次；复杂：>10 严格分工）
- MCP 可以访问的工具参次不齐，通过启发式规则让智能体调度不同工具。
- 用 LLM 诊断并分析原因，发现问题并解决问题。
- 搜索策略应当先广泛探索，再聚焦细节。
- 将扩展思考（extended thinking）作为可控草稿板，显式化规划与复盘。
- 化串行为并行，多任务并发处理实现缩短复杂查询耗时≈90%。
- 复杂问题，先拆解为原子级任务，批判地看待搜索结果，动态调整搜索策略，在深度与广度之间取舍，通过人与测试用例防止逻辑幻觉或进入死循环。
- 灵活且高质量的评估很重要，在一开始就用少量示例开展小规模测试，而不是等到可以构建更全面的评测后才开始。
- 充分使用 LLM 作为评审，单次打分0.0–1.0+通过/不通过；维度含事实、引文、完整性、来源质量、工具效率。
- 避免智能体总是倾向选择经过SEO优化的内容，更多采用质量启发式。
- 构建一套协作框架，明确分工、问题解决路径以及投入预算
详细可参考 Anthropic GitHub Agent ，这里展示了实现三种简单的多LLM（大型语言模型）工作流程，以及如何设计能够在某些任务上获得更优的表现。
Agent 系统中，即便是微小的变更，也会引发很大范围的行为变化，所以需要在长时间运行过程中能够保持高质量的代码编写。逐步切流避免打断长程运行智能体。
Agent 和提示词一样，即便提示词都相同，但每次运行的结果也可能不同，这使得工作更具挑战性。
值得注意的一点是，当出现故障时，及时告知智能体并让其自适应，效果往往出乎意料地好。
AI Agent 从原型到生产的过程比提示词要复杂得多。它们像一条多环链，只要其中一步出错，就可能让整个行为轨迹偏离，产生不可预测的结果。原型在本地跑得很好，但要在生产环境中稳定运行，需要额外大量工程投入，原型与上线之间的距离通常比我们想象的更远。
文末 Anthropic 给出了最常见的用例分类占比：
- 跨专业领域开发软件系统（10%）
- 开发与优化专业及技术内容（8%）
- 制定业务增长与收入策略（8%）
- 协助开展学术研究和教育资料开发（7%）
- 以及研究和核实有关人物地点或组织的信息（5%）。
Agent 的这些问题，实际都是面对一些复杂且重要任务时大家所关心的问题。之前都是手工地整理结论，人工不断采样、再次分析，更多时候不得不让多个模型去交叉回复，甚至把各个厂商提供的 DeepResearch 功能交叉起来总结分析。这个过程对使用者的角度来看到也收获不少。
随着用 Codex, Antigravity等工具进行编程的时候，迷茫随之而来。因为并不是每次看上去很好的方案，工具都能完美实现。更别说偷懒，假设存在地编程。偶尔甚至自作主张用 Mock 方式来来避免更多的工作、重构。就如 CC 的产品经理说的那样，一个好方案会减少后边好多麻烦，这个角度看来也许是方案并不是那么的优秀。所以让模型/工具先写详细的方案，然后再开工是更好的选择。但复杂一点的项目结局都是写了无数的总结文档依然屡屡犯错，还美其名曰 Compounding Coding。
尽管多智能体系统在实现上充满挑战，但它们在开放式探索和研究任务中已经展现出不容忽视的价值。这和 8 号跑步的的时候听 张小珺采访 Manus中说到的道理类似，有很多人还是愿意为这些真正能解决问题的工具付费，而且所涉及的领域非常庞大，并不仅仅只有 Coding。日常写一份 ppt，投资中的一次企业财报分析，金融企业的信审，全球企业的法务事件应急处理…
几次简单的对话完全不具备内外部的信息量，大量的文档搜集处理所需的资源却又极其庞大… 想来这也是为什么 Manus 在短短的 9 个多月就能有 1 亿多美金收入的原因了。
把 AI Agent 从原型带到生产，难点不在提示词，而在工程：状态与记忆管理、工具调用的可靠性、权限与合规、延迟与成本、监控与回滚。链条任一环失效，行为就会偏离。原型能跑不等于线上可交付，从 Demo 到稳定 SLA，往往隔着一整套可靠性建设。
以任务为中心、内置检索与长期记忆、指标驱动的评测与可观测性、人类在环与合规约束、以及对成本与延迟的动态优化。当这些环节成熟，为解决问题付费的用户群将持续扩大，覆盖行业也会更广。
讨论
登录后可评论、点赞、引用回复。