凡人小北

读完 Anthropic 的多智能体系统文章，有几个点挺触动的，尤其是放回我们平时在做 agent 编排和系统落地的过程中，对应起来很多痛点被他们提前踩过、总结得非常系统。 这套系统看上去是给 Claude 提升复杂研究任务能力，底层其实是三个关键词：带宽、结构、机制。 1️⃣从 token 到带宽：扩容问题其实是系统问题 他们很明确地说，单个 agent 很快就会遇到 token 限制，这不是模型能力不行，而是容量不够。很多时候 LLM 的“不会”、“忘了”、“答不出来”，只是 context 塞不下。这一点在我们自己调长链条、多跳调用的时候也很明显。Anthropic 选择的解法不是扩模型，而是拆任务、开并发、分 agent，每个 agent 自带上下文窗口，从系统结构层面扩容。 这种设计非常实用，因为它绕过了 token 墙的天然限制，通过多 agent 并发变相把 token 维度拉开了。这是我最近做 agent 编排时反复体会到的：不是把 prompt 写得多聪明就能解决，而是要想清楚结构怎么设计，谁来拉信息、谁来拼结构、谁来追引用。 2️⃣提示词是系统指令，很重要、很重要、很重要！ 这篇文章有个细节写得特别清楚：主 agent 的提示词，是负责分配任务、指明目标、交代格式、选工具的。这个逻辑其实是我们做复杂 agent 系统中很容易忽略的一块：提示词不只是沟通语言，更是调度逻辑、任务协议、格式规范的集中承载体。 尤其是多个 agent 并行运行时，如果没有一个清晰、格式化、结构稳固的 prompt 模板，每个子 agent 拉回来的信息会特别散、错漏率高、很难合并。这时候，主 agent 的提示词就等于一个调度中枢的“编程语言”。 从我们平时用的实践来看，这就意味着主 agent 的提示词策略应该和流程图一样严谨：每一步要预设结果、预设失败、预设上下游。这块我觉得是现阶段很多 agent 框架还不够成熟的地方。 3️⃣系统级机制，决定了能不能撑进生产环境 我觉得特别值得借鉴的工程概念：checkpoint、异步重试机制、全链路 tracing、彩虹部署。这几个在大数据异步系统里很常见概念，AI 领域得好好学习下。 这些词不是为了好听，它们背后都是在回答一个问题：这个系统崩了怎么办？agent 卡死怎么办？升级逻辑还没验证好怎么办？一整套机制让这个系统不是在 demo 一个可能性，而是在上线跑任务、自动修复、平滑演进。 平时我们在做流程型 AI 系统的时候，很容易只关注“怎么生成”“怎么判断好坏”，但 Anthropic 的做法提醒我：agent 系统本质上要往服务化方向走，就必须预设失败是常态，重试是能力。 4️⃣评估机制是不可缺的闭环，不然做不出反馈导向的系统进化 他们有一个细节很打动我：让另一个 LLM 去评审 agent 的结果，从准确性、引用合理性、覆盖度等多个维度打分。这就相当于在系统里内嵌了 QA 流程，而且不是事后人评，而是可以插入调试链路的 LLM 评测器。 我们自己在调多 agent 结构时常遇到一个问题：任务执行完了，但结果质量很难量化，只能靠人工判断或者事后比对。这套“LLM 评估 LLM”的机制，让我们开始可以想象一种更自动化的 agent 演化路径：系统自己跑，自己打分，自己选择 prompt A 还是 B，更适合持续调优。 5️⃣并发是工具，不是策略，适用场景边界要想清楚 这套系统最适合的场景是：问题复杂度高、信息广度要求强、非实时产出型任务。例如政策研判、产品调研、文献综述、竞品分析这些，在私域服务里也可以类比成“多维标签用户意图研判”这种复杂工作。 但如果放在需要紧密配合、频繁迭代、低延迟要求的任务上，例如代码生成、对话任务、实时接口构建，多 agent 的协调成本反而可能放大系统复杂度。所以并发结构是个好工具，但什么时候该开几个 agent，什么时候该单线程跑到头，这种策略边界要想清楚。 这篇文章最核心的不是“我们做了一个多 agent 系统”，而是他们已经把多 agent 作为一种工程能力进行制度化建设：有流程、有容错、有评估、有上线机制。 对在第一线实际落地 AI 能力的团队来说，有一个非常直接的启发是：构建 agent 系统，不能只是对话式的 prompt 编排，而要像搭服务一样，从任务定义到评估反馈，从并发机制到异常兜底，形成一整套可以持续运行的系统逻辑。 这一点，比起模型调优，本质上更像是一种架构能力的竞争。