# 企业级 Agent 构建指南
**作者**: Miles.
**日期**: 2026-05-19T07:08:57.000Z
**来源**: [https://x.com/ma_zhenyuan/status/2056633189687586958](https://x.com/ma_zhenyuan/status/2056633189687586958)
---
上个月给一个客户定制了一套 Deep Research 系统，本质就是多 Agent，客户的报价 12W。
AI 变现的正确姿势，不是卖课，不是做中转站，而是做企业级项目定制。
每个月花 30-40 小时接 1～2 个项目，月入 8 万，有手就行。
这篇文章，我会用最通俗易懂的话，拆解 Deep research 的核心，你看懂了 Deep Research，你就知道企业级 Agent 怎么搭建了。
## 1、到底什么是 Agent
Agent 不是"更聪明的 AI"，是"会自己动手的 AI"。
传统 AI 对话是一问一答。你问"今天北京天气怎么样"，AI 说"抱歉，我无法获取实时信息"。对话结束。
Agent 不一样。你问"今天北京天气怎么样"，Agent 自己调用天气 API，告诉你"今天北京晴天，15-25 度，适合出门"。
Agent 的核心能力不是回答问题，是解决问题。
具体来说，Agent 能做三件事：
一是调用工具。工具可以是搜索引擎、数据库、代码执行器。Agent 知道什么时候该用什么工具。你问"特斯拉最新股价"，Agent 调用金融数据 API。你问"帮我写个 Python 脚本"，Agent 调用代码执行器。
二是自己规划。你给 Agent 一个复杂任务，它会自己拆解成多个步骤。你说"帮我调研 AI Agent 市场"，Agent 自己规划：先搜索定义，再搜索市场规模，再搜索主要玩家，最后整理成报告。
三是从反馈中调整。Agent 调用工具后，会看结果是否符合预期。不符合就调整策略，再试一次。Agent 搜索"AI Agent 市场规模"，发现结果都是 2023 年的旧数据。它会调整关键词，改成"AI Agent 市场规模 2025"。
这三个能力组合起来，Agent 就能处理复杂任务。
## 2、什么时候需要 Agent
从第一性原理出发，我的建议是：找最简单的解决方案，只在需要时增加复杂度。
简单任务，优化单个 LLM 调用就够了。比如文本分类、内容总结、简单问答，用一个精心设计的提示词，加上几个示例，就能解决。不需要 Agent，不需要工具，一次调用搞定。
中等任务，用 Workflow。Workflow 是预定义的代码路径，LLM 在每个步骤执行特定任务。比如"生成营销文案 → 翻译成多种语言"，或者"写文章大纲 → 检查大纲 → 根据大纲写文章"。Workflow 的好处是可预测、易调试。你知道每一步会发生什么，出错了也知道在哪一步出错。
复杂任务，才需要 Agent。Agent 适合开放式问题，难以预测需要多少步骤，无法硬编码固定路径。比如调研一个陌生领域、解决 GitHub issue、处理复杂的客服咨询。这些任务的特点是：你不知道需要搜索多少次、不知道会遇到什么问题、不知道需要调用哪些工具。
Agent 和 Workflow 的核心区别：Workflow 是你告诉 AI 怎么做，Agent 是 AI 自己决定怎么做。
从实战角度看，Agent 特别适合两类任务。
一类是信息入口很复杂的任务。比如客服、投研、招聘筛选、企业知识库问答。用户的问题不固定，系统可能需要查订单、查政策、查数据库、读文档、调用内部系统。你很难提前把所有路径写死，只能让 Agent 根据问题现场判断。
另一类是执行路径不确定的任务。比如修复一个 GitHub issue、分析一份陌生数据、调研一个新市场。你不知道一开始要查多少资料，也不知道会遇到什么坑。Agent 的价值就在这里：它可以边做边看结果，再决定下一步。
所以我判断一个任务要不要用 Agent，通常看一个问题：这个任务能不能提前写成稳定流程？能，就先用 Workflow。不能，再考虑 Agent。
## 3、Agent 是怎么工作的
Agent 的工作方式是"循环"。不是"你问一句，我答一句"，而是 "思考 → 行动 → 观察结果 → 再思考" 的循环，直到任务完成。这个循环叫 ReAct（Reasoning + Acting）。
举个例子，你让 Agent 找"2025 年最火的 AI 工具"。Agent 先搜索"2025 AI tools"，发现结果里都是 ChatGPT、Gemini、Midjourney。这些工具 2024 年就有了，不是"2025 年最火的"。
Agent 调整策略，改成搜索"AI tools launched in 2025"。这次找到了 Sora 和 Gemini 3.0。找到了，任务完成。
整个过程就是不断尝试、调整、优化。不是一次性给答案，而是根据反馈调整策略。
## 4、为什么需要多个 Agent
单个 Agent 已经很强了，为什么还需要多个？因为单个 Agent 有两个致命问题。
一是记忆会满。 AI 的"工作记忆"是有限的。AI 每次思考，都需要把之前的对话历史、工具调用结果、中间结果全部加载到"工作记忆"里。这个"工作记忆"叫上下文窗口。
现在很多模型都支持很长的上下文窗口，从几十万到上百万 Token 不等。Token 是 AI 处理文本的最小单位，1 个 Token 大约等于 0.75 个英文单词，或者 1.5 个中文字。100 万 Token 大约是 60 万中文字。
听起来很大，但如果你让 Agent 做一个复杂调研，搜索 200 个网页，每个网页 3000 字，光是搜索结果就 60 万字了。上下文满了，Agent 就"记不住"之前做了什么，开始出错。
为什么上下文满了，Agent 就"记不住"？因为 AI 的注意力是有限的。这源于 Transformer 架构的特性：AI 处理上下文时，需要计算每个 Token 和其他所有 Token 之间的关系。如果有 10 万个 Token，就需要计算 10 万 × 10 万 = 100 亿次关系。这种 n² 的计算复杂度，导致上下文越长，AI 的注意力越分散。
研究人员把这个现象叫"上下文腐烂"（context rot）。随着上下文窗口中 Token 数量的增加，模型准确回忆信息的能力会下降。就像你同时看 50 本书，每本书都只能记住一点点。
二是效率低。 单个 Agent 只能"串行"工作。做完第一件事，才能做第二件事。你让 Agent 调研"AI Agent 的三个主要应用场景"，它需要搜索"AI Agent 客服应用"（1 分钟）、搜索"AI Agent 编程应用"（1 分钟）、搜索"AI Agent 数据分析应用"（1 分钟），总共 3 分钟。
但如果有 3 个 Agent，可以同时搜索，理论上只需要 1 分钟。实际系统里还会有调度、汇总和去重的成本，不一定线性加速，但并行一定能缩短等待时间。
更重要的是，多 Agent 架构不是只为了快，而是为了扩展"可处理的信息量"。 单个 Agent 的上下文窗口再大，也要把所有材料塞进一个脑子里。多个 Agent 可以把任务分散到独立的上下文窗口里，每个 Agent 只处理自己那一部分材料，最后再汇总。
但多 Agent 不是免费的。 它会消耗更多 Token，发起更多工具调用，也更难调试。对普通问答来说，这完全是浪费。只有当任务本身足够复杂、结果价值足够高，才值得用多 Agent 换取更大的信息覆盖和更高的完成率。
多 Agent 把任务拆开，每个 Agent 负责一部分。你让系统调研"AI Agent 市场"，可以分成 3 个子任务：Agent A 负责调研市场规模，Agent B 负责调研主要玩家，Agent C 负责调研技术趋势。每个 Agent 有自己独立的上下文窗口，互不干扰。3 个 Agent 同时工作，效率提升 3 倍。
单个 Agent 是员工，多个 Agent 是团队。
## 5、多 Agent 是怎么协作的
多个 Agent 怎么配合？谁先做？谁后做？谁的结果给谁？有两种模式：编排模式和自主模式。
编排模式就像一个乐队，有一个指挥，告诉每个乐手什么时候演奏。 在多 Agent 系统里，有一个"主 Agent"负责规划和协调，其他"子 Agent"负责执行具体任务。
工作流程是这样的。用户给主 Agent 一个任务："帮我调研 AI Agent 市场"。主 Agent 拆解任务：调研市场规模、调研主要玩家、调研技术趋势。主 Agent 创建 3 个子 Agent，分别负责 3 个子任务。3 个子 Agent 并行工作，各自搜索信息。3 个子 Agent 把结果返回给主 Agent。主 Agent 整合结果，生成最终报告。
这就是 Deep Research 的工作方式。编排模式的好处是分工明确，不会乱。主 Agent 可以控制全局，避免子 Agent 跑偏。坏处是主 Agent 需要很强的规划能力。如果主 Agent 规划错了，整个任务就失败了。
自主模式就像一个创业团队，没有固定的老板，大家根据情况自己决定做什么。 在多 Agent 系统里，每个 Agent 都是平等的，可以自己决定下一步做什么，也可以主动找其他 Agent 协作。
工作流程是这样的。用户给系统一个任务："帮我调研 AI Agent 市场"。Agent A 说："我去搜索市场规模数据"。Agent B 说："我去搜索主要玩家"。Agent C 说："我等 A 和 B 搜完，我再整合结果"。A 和 B 并行工作。C 等 A 和 B 完成后，整合结果。
自主模式的好处是灵活，可以根据情况动态调整。不依赖单个主 Agent，更鲁棒。坏处是协调复杂，容易出现冲突。难以调试，不知道哪个 Agent 出了问题。
目前，大部分多 Agent 系统用的是编排模式，因为更稳定、更容易控制。
多 Agent 系统的挑战不容忽视。
错误会复合。 单个 Agent 出错，可能只影响一个任务。但在多 Agent 系统里，一个 Agent 的错误会传递给其他 Agent，导致整个系统失败。就像多米诺骨牌，一个倒了，后面全倒。主 Agent 规划错了，所有子 Agent 都在做无用功。子 Agent 返回了错误信息，主 Agent 基于错误信息生成错误报告。
调试困难。 单个 Agent 出错，你知道是哪里出了问题。但多 Agent 系统，你不知道是主 Agent 规划错了，还是某个子 Agent 执行错了，还是 Agent 之间的协调出了问题。所以生产系统必须有完整的追踪（tracing），记录每个 Agent 的决策、工具调用、返回结果。出错时，要能回溯整个过程，找到问题根源。
状态管理复杂。 多 Agent 系统是有状态的，Agent 可能运行很长时间，维护大量中间状态。如果系统崩溃，重启的成本很高。更合理的做法是定期保存检查点，出错时从检查点恢复，而不是从头开始。同时，Agent 要能优雅地处理错误。比如，工具调用失败时，系统要告诉 Agent"这个工具暂时不可用"，让它自己决定是换一个工具，还是调整策略。
所以，多 Agent 系统不能一上来就直接丢到生产环境。 它需要沙箱测试、权限控制、错误处理、日志追踪和人工接管机制。Agent 越能自己行动，越要认真设计边界。
## 6、多 Agent 如何传递信息
多个 Agent 之间需要传递信息。怎么传？
最简单的方式是直接传递。Agent A 把自己搜索到的所有内容，原封不动地传给 Agent B。问题是信息太多，下一个 Agent 处理不过来。Agent A 搜索了 10 个网页，每个网页 3000 字，总共 3 万字。Agent B 拿到 3 万字的原始内容，需要花很多时间阅读和理解。而且，这 3 万字里可能有很多无关信息。Agent B 需要自己筛选，效率很低。
更好的方式是总结传递。Agent A 先总结自己搜索到的内容，只把关键信息传给 Agent B。Agent A 搜索 10 个网页，得到 3 万字的原始内容。Agent A 用 AI 总结这 3 万字，提取关键信息，压缩成 3000 字。Agent A 把 3000 字的总结传给 Agent B。Agent B 只需要阅读 3000 字，效率提升 10 倍。
这也是 Deep Research 类系统普遍会采用的做法。子 Agent 不应该把原始搜索结果一股脑丢回来，而应该返回经过筛选和压缩的发现。
更进一步，可以让 Agent 用统一的格式传递信息。每个 Agent 返回的信息都包含：主题（这段信息讲的是什么）、关键发现（最重要的 3 个结论）、来源（信息来自哪个网页）。这样，下一个 Agent 可以快速理解信息的结构，不需要自己去提取。
举个例子。Agent A 搜索"AI Agent 市场规模"，返回：主题是 AI Agent 市场规模，关键发现是 2025 年全球 AI Agent 市场规模预计达到 50 亿美元、年增长率 40%、主要增长来自企业客服和编程辅助，来源是某市场报告网站。Agent B 拿到这个结构化的信息，可以直接使用，不需要再处理。
信息传递的核心原则：传递结论，不传递过程。
## 7、上下文是怎么管理的
上下文是 Agent 的"工作记忆"。多 Agent 系统的上下文管理更复杂。
上下文包括用户的原始问题、系统提示词（告诉 Agent 它的角色和任务）、工具定义（Agent 可以调用哪些工具）、对话历史（之前说了什么、做了什么）、工具调用结果（搜索到了什么、代码执行结果是什么）。所有这些信息，都需要加载到 Agent 的"工作记忆"里。
如果 Agent 做一个复杂任务，上下文会越来越大。Agent 搜索了 50 个网页，每个网页 3000 字，光是搜索结果就 15 万字。加上对话历史、工具定义，很快就会逼近模型的上下文上限。即使没有真正超过上限，内容太多也会让模型抓不住重点。就像你的电脑内存还没爆，但程序已经开始卡。
多 Agent 系统用三种方法解决上下文爆炸。
一是分散上下文。 每个子 Agent 有自己独立的上下文窗口。主 Agent 只需要记住"我分配了哪些任务"，不需要记住每个子 Agent 的搜索结果。子 Agent 只需要记住"我负责的任务是什么"，不需要记住其他子 Agent 的工作。这样，每个 Agent 的上下文都很小，不会爆炸。
二是压缩上下文。 当上下文快满的时候，Agent 会自动压缩。压缩的方式是：用 AI 总结之前的对话历史和工具调用结果，把 10 万字压缩成 1 万字。保留任务目标、关键发现、已做过的尝试、失败原因和下一步计划，丢弃冗余内容。
三是外部记忆。 Agent 可以把一些信息存到"外部记忆"里，不放在上下文里。比如把搜索结果、代码分析、数据中间表、任务日志存到文件或数据库里，需要的时候再读取。这就像人类做笔记。你不需要把所有信息都记在脑子里，可以写在笔记本上，需要的时候翻笔记。
上下文管理的核心原则：只记住必要的，忘掉冗余的。
## 8、Deep Research 是怎么工作的
现在我们可以拆解 Deep Research 了。
Deep Research 是一个典型的多 Agent 系统，采用编排模式。 举个例子，它有三个角色：主 Agent（Lead Researcher）负责理解用户的问题、拆解任务、创建子 Agent、整合子 Agent 的结果、生成最终报告。子 Agent（Sub-Agent）负责执行具体的搜索任务，每个子 Agent 负责一个子主题，子 Agent 之间并行工作，互不干扰。引用 Agent（Citation Agent）负责给报告添加引用，确保每个结论都有来源。
工作流程分六步。
1）用户输入："帮我调研 AI Agent 在 2025 年的主要应用场景"。主 Agent 会先问几个问题，澄清用户的需求：你想了解哪些行业的应用？你更关注技术细节还是商业模式？你需要多详细的报告？用户回答后，主 Agent 生成一个"研究计划"，明确调研的范围和目标。
2）主 Agent 把任务拆解成多个子任务：调研 AI Agent 在客服领域的应用、调研 AI Agent 在编程领域的应用、调研 AI Agent 在数据分析领域的应用。
3）主 Agent 创建 3 个子 Agent，分别负责 3 个子任务。每个子 Agent 拿到的信息包括：原始问题、子任务、工具（搜索引擎、代码执行器）。
4）3 个子 Agent 同时开始工作。以"客服领域"的子 Agent 为例。它先搜索"AI Agent customer service 2025"，找到 10 个网页，总结出 AI Agent 在客服领域主要用于自动回复、工单分类、情绪分析。然后搜索"AI Agent customer service case study"，找到相关案例。最后搜索"AI Agent customer service limitations"，找到局限性分析。子 Agent 完成搜索后，把总结返回给主 Agent。
这个过程中，子 Agent 使用了"交错思考"（interleaved thinking）。每次调用工具后，子 Agent 会评估结果质量、识别信息缺口、优化下一次查询。这种思考模式让子 Agent 能够根据实际搜索结果动态调整策略，而不是机械地执行预设步骤。
5）主 Agent 收到 3 个子 Agent 的总结：客服领域（自动回复、工单分类、情绪分析）、编程领域（代码生成、代码审查、Bug 修复）、数据分析领域（数据清洗、可视化、报告生成）。主 Agent 把这些总结整合成一份完整的报告。
6）引用 Agent 检查报告中的每个结论，找到对应的来源，添加引用。整个过程大约需要 5-10 分钟。
Deep Research 有几个关键设计。子 Agent 只返回总结，不返回原始内容，这样可以大幅减少上下文压力。子 Agent 之间完全隔离，每个子 Agent 有自己独立的上下文窗口，互不干扰。主 Agent 负责全局协调，决定创建几个子 Agent、每个子 Agent 负责什么任务、什么时候结束。并行工作，提高效率，3 个子 Agent 同时工作，效率提升 3 倍。
## 9、多 Agent 的评估和迭代
多 Agent 系统很复杂，怎么知道它做得好不好？
传统软件的评估很简单：输入 X，输出 Y，检查 Y 是否正确。但 Agent 不一样。同样的输入，Agent 可能走完全不同的路径。你让 Agent 调研"AI Agent 市场"，Agent A 可能搜索 3 个网页，Agent B 可能搜索 10 个网页。两个 Agent 的路径不同，但都可能得到正确的结果。所以，评估 Agent 不能只看"路径是否正确"，而要看"结果是否正确"。
评估多 Agent 系统，至少要看三层。
一是小样本快速测试。 在早期开发阶段，准备 20 个典型问题，每次改动后跑一遍，看结果是否变好。20 个问题听起来很少，但在早期阶段够用了。因为早期的改动效果很明显，20 个问题就能看出差异。
二是 LLM 评估。 让另一个 LLM 当"评委"，评估 Agent 的输出质量。评估维度包括：事实准确性（结论是否符合来源）、引用准确性（引用的来源是否支持结论）、完整性（是否覆盖了所有要求的方面）、来源质量（是否使用了高质量的来源）。
三是人工评估。 让真人测试 Agent，找出自动化评估发现不了的问题。比如 Deep Research 类产品很容易优先引用 SEO 优化过的内容农场，而不是权威报告、论文或一手资料。这个问题自动化评估不一定能发现，因为内容农场的文字"看起来"也很完整。
真正迭代 Agent 系统，主要优化三个方向。
优化提示词。 提示词是 Agent 的"操作手册"。提示词写得好，Agent 就做得好。比如要明确告诉主 Agent：简单问题不要拆太多子任务；直接比较可以拆成 2-4 个子任务；复杂研究才需要更多子 Agent。否则它很容易为了显得努力，创建一堆没必要的子任务，最后成本高、速度慢、结果还重复。
工具选择也要写清楚。Agent 应该先检查有哪些工具，再匹配用户意图，优先使用专用工具，而不是一上来就用通用搜索。比如查股价应该用金融数据工具，不应该去网页搜索；查内部订单应该用订单系统，不应该问模型猜。
优化工具。 工具的设计直接影响 Agent 的效率。很多 Agent 项目最后卡住，不是因为模型不够聪明，而是工具太难用。
工具设计的核心原则：让模型"容易写"。 比如，让模型写 diff 格式的代码修改，模型需要提前计算有多少行代码变化，这很难。但如果让模型直接重写整个文件，就容易多了。再比如，让模型在 JSON 里写代码，需要转义所有换行符和引号，模型经常出错。但如果让模型在 Markdown 代码块里写代码，就不需要转义，错误率大幅下降。
工具描述要像"给初级开发者写文档"。包括使用示例、边界情况、输入格式要求、与其他工具的区别。如果你自己看工具描述都要仔细想，模型也会困惑。写完工具描述后，最好让另一个人或另一个模型读一遍，看能不能理解。
这可以理解成 Agent-Computer Interface（ACI），也就是 Agent 和工具之间的交互界面。就像 Human-Computer Interface（HCI）需要精心设计，ACI 也需要同样的投入。好的 ACI 设计包括：给模型足够的"思考空间"（不要让模型在写代码前就要确定代码行数）、保持格式接近自然文本（不要用复杂的转义）、减少格式开销（不要让模型数行数、转义字符串）。
实战里甚至可以专门做一个"工具测试 Agent"。让它反复使用某个工具，记录哪里容易出错、哪里描述不清、哪里参数设计反直觉，再反过来优化工具和说明文档。这类投入看起来琐碎，但会直接影响后续 Agent 的完成率和速度。
优化协调机制。 多 Agent 之间的协调很重要。如果主 Agent 创建 3 个子 Agent，然后必须等 3 个全部完成后再继续，就会被最慢的那个拖住。更好的方式是异步处理：哪个子 Agent 先完成，就先处理哪个结果；某个子任务卡住，也不影响其他结果先进入汇总。
## 10、多 Agent 的未来
多 Agent 系统还在快速发展，未来会有哪些变化？
现在的多 Agent 系统，协调机制还比较简单。主 Agent 分配任务，子 Agent 执行任务，主 Agent 整合结果。未来，Agent 之间可能会有更复杂的协调。子 Agent 可以主动向主 Agent 请求更多资源："我发现这个子任务比预期复杂，需要更多时间。"或者，子 Agent 之间可以直接协作："我发现你负责的子任务和我的有重叠，我们可以共享信息。"
现在的多 Agent 系统，通常在几分钟到几十分钟内完成任务。未来，Agent 可能会处理更长时间跨度的任务。你让 Agent 帮你"持续追踪 AI 行业的最新动态"，Agent 可以每天自动搜索新闻、整理报告，持续几个月。这需要更强的记忆管理能力。Agent 需要记住"上周我搜索了什么"，避免重复工作。
现在的多 Agent 系统，主要用于调研和搜索。未来，多 Agent 可能会用于更多场景。
编程场景：主 Agent 负责理解需求，拆解任务。子 Agent 负责写代码、测试、部署。引用 Agent 负责写文档。
数据分析场景：主 Agent 负责理解分析目标。子 Agent 负责数据清洗、可视化、建模。引用 Agent 负责生成报告。
内容创作场景：主 Agent 负责理解创作主题。子 Agent 负责搜索素材、写初稿、配图。引用 Agent 负责校对和优化。
## 写在最后
看懂了 Deep Research，你就看懂了 Agent。
Deep Research 的核心是多个 Agent 协作。主 Agent 负责规划和协调，子 Agent 负责执行具体任务，引用 Agent 负责添加引用。
多 Agent 的关键设计是分散上下文压力，每个 Agent 有独立的上下文窗口。并行工作，提高效率。传递结论，不传递过程。
下次你用 Deep Research、浏览器 Agent 或代码 Agent 的时候，试着观察它是不是在"循环"工作。如果是，你就看到了 Agent 的工作方式。
## 相关链接
- [Miles.](https://x.com/ma_zhenyuan)
- [@ma_zhenyuan](https://x.com/ma_zhenyuan)
- [4.1K](https://x.com/ma_zhenyuan/status/2056633189687586958/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:08 PM · May 19, 2026](https://x.com/ma_zhenyuan/status/2056633189687586958)
- [4,141 Views](https://x.com/ma_zhenyuan/status/2056633189687586958/analytics)
- [View quotes](https://x.com/ma_zhenyuan/status/2056633189687586958/quotes)
---
*导出时间: 2026/5/19 17:38:50*