企业官网建设流程全解析

做了几十个 Agent，在某次内部演示里把所有流程跑通时，团队确实很兴奋。但兴奋劲过去之后，你可能会发现一个更真实的问题：这些 Agent 单独拿出来都能跑，可一旦要放进正式业务里，就开始不断暴露出小毛病——幻觉、超时、上下文串了、依赖更新了、权限配错了、跑一次成功跑第二次失败。更让人沮丧的是，你做了几十个，却没有一个真正在线上长期稳定地产生价值。

如果要在各种 Agent 开发热潮里挑一个最容易被误解的事实，我可能会说：能把几十个 Agent 做出来，恰恰说明你可能还停留在 AI 落地的第一阶段。这个阶段的核心能力是“把单个流程用大模型跑通”，但它距离真正意义上的业务落地，还差着一整套工程化、系统化和治理化的能力。这篇文章想拆开的，就是这件事。

1. 先承认一个事实：几十个 Agent 很容易做出来

1.1 为什么 Agent 开发门槛被大幅拉低了

过去几年，大模型的能力快速提升，底座模型本身已经帮你解决了很多“理解”和“生成”的工作。到了 Agent 层面，你不需要再去训练一个模型，你只需要把模型包装成一套能够自主执行任务的流程——给它一个目标，让它调用工具、读取信息、生成结果。很多框架已经把这层包装做得很成熟，你只要写几个函数、配一个提示词、定义好输入输出，一个 Agent 就活了。

在常见实践里，一个最简单的 Agent 可能只需要走五步：

• 定义一个系统提示词，告诉模型它是什么角色、要做什么、不能做什么。
• 给它几个工具函数，例如查数据库、调用 API、读文件、写文件。
• 设定任务入口，接收用户输入或定时触发。
• 让模型决定调用哪个工具、按什么顺序调用。
• 对工具返回结果进行后处理，输出最终答案或触发下一步操作。

框架层还会帮你处理模型调用、工具注册、多轮对话、重试逻辑等大量基础工作。所以，有一个经验大家都应该能感受到：现在开发一个 Agent 的成本，已经从“需要算法团队研究几个月”变成了“一个普通开发者花一下午搭个 demo”。

这不是贬低 Agent 开发，而是说这是一件好事。技术门槛降低，意味着更多人能参与进来，更多业务场景能被尝试覆盖。我自己也做过很多类似的东西，包括自动写周报的、自动整理会议纪要的、自动检查代码规范的、自动回复常见客服问题的等等。它们看起来都不复杂，但刚做完的时候确实很有成就感，因为每一个都是“能跑”的。

1.2 但“能做出来”和“能落地”是两种能力

随时间积累，当你做了十几个、几十个 Agent 之后，一个隐秘的变化会发生：你开始分不清自己是在“做产品”还是在“攒玩具”。它们之间的本质区别，不是功能的多少，而是有没有进入一个真实的业务闭环里被反复考验。

如果你只是做出来给自己用，或者只是为了验证某个模型能力，那“能跑”就完成了它的使命。但如果是要给团队、给客户、给组织长期使用，那“能跑”只是起点。真正落地时，你要处理的问题瞬间变多：

• 这个 Agent 在 99% 的情况下都能给出正确结果吗？
• 结果错误时，能不能被及时识别出来？
• 模型换了版本，输出风格变了，会不会导致流程突然崩溃？
• 工具重启、网络超时、数据源变更时，Agent 有没有恢复能力？
• 多个 Agent 同时处理任务时，会不会互相干扰？
• 调用成本、响应延迟、并发上限，能不能支撑真实流量？
• 它有没有可能在某种边界条件下做出一件你不希望它做的事情？

这些问题，很多不是“做一个 Agent”时会考虑的，但它们才是落地的关键。做一个 Agent，像是组装一台可以启动的汽车；落地一个 Agent，像是让这台汽车通过碰撞测试、适应不同路况、遵守交通规则、纳入车辆调度系统，然后才能跑在同一条生产线上。

2. 为什么大量实践停留在“AI 落地第一阶段”

2.1 第一阶段的核心特征：解决单点任务，忽略系统性问题

我把 AI 落地分成了两个明显的阶段，不是用模型能力来划分，而是用“问题层级”来划分。

第一阶段，叫做“单点任务自动化”。这个阶段解决的问题非常具体：原来需要人工反复操作的事情，现在交给一个 Agent 去自动完成。例如自动汇总数据、自动生成文本、自动分类邮件、自动抽取结构化信息。这些任务有一个共同点：边界清晰，输入输出可控，失败后的影响范围也比较小。它们非常适合作为 Agent 开发入门，因为模型能力已经足够覆盖这些需求的落点，不容易出现复杂依赖。

大多数团队做几十个 Agent，基本都停留在这个阶段。每个 Agent 对应一个独立任务，它们像一个个“小工具”散落在不同的目录里，有的通过脚本调用，有的封装成了接口，有的只是手动粘贴文本触发。这种模式没有错，它甚至有效解决了若干局部问题。但你会发现几个现象：

• 每个 Agent 之间的数据流是断裂的。A 的输出往往是 B 的输入，但你需要手工搬运。
• 每个 Agent 的提示词和工具逻辑相互独立，出现业务变化时，要逐个修改。
• 没有一个统一的评测标准，你很难说“这个 Agent 的准确率是 90% 还只是运气好”。
• 日志、异常处理、权限管理都很随意，出了问题只能靠人工回溯。

这还不是最关键的。最关键的是，当你把一个单点任务自动化之后，你并没有改变整个业务流程的结构。你还是原来的流程，只是把某个步骤换成了模型来跑。这种替换能带来局部效率提升，但不等于完成了 AI 转型。

2.2 从几十个 Agent 里找共性：它们通常是“一次性玩具”而不是“生产服务”

我们可以做一个很直接的盘点。回顾你最近做过的几十个 Agent，它们可能符合下面至少一条特征：

• 跑过几次就拿去演示了，之后很少再使用。
• 只在特定输入下表现良好，换个数据结构就失效。
• 没有版本管理，提示词改了以后没有留痕，也没法回滚。
• 没有自动化测试，模型输出是否合格全凭人眼判断。
• 没有监控，Agent 跑丢了、跑偏了、报错了，只能在别人反馈时才知道。
• 没有服务化，只在开发机上有环境依赖，换一台机器就起不来。

如果一个 Agent 符合以上任何一条，那它更接近一个“一次性玩具”。玩具的价值在于验证可能性，生产服务的价值在于持续、稳定地交付价值。做几十个玩具，只能说明你或你的团队在“探索”上很积极，但还不能说明你已经在“落地”。

我不认为玩具没有价值。相反，我认为探索是必须的。但如果你满足于停留在玩具阶段，那你对 Agent 的认知就会产生偏差。你会误以为“哦，Agent 不过如此”，或者“Agent 很容易做，但就是不实用”。实际上，不是 Agent 不实用，是你没有把工程化理论和系统工程思想放进去。

2.3 第二阶段才真正开始：稳定性、可观测性、评估、成本、安全

AI 落地真正的分水岭，在于你能不能回答下面这些系统性问题：

• 稳定性：同一个输入重复 100 次，输出的合格率是多少？波动范围有多大？
• 可观测性：Agent 在执行过程中调用了哪些工具、读到了什么信息、做了哪些决策？如果结果不合格，能不能追溯到是哪一步出了问题？
• 可评估性：你有没有一套定量的、可持续更新的评测集，用来衡量 Agent 在不同版本之间的表现变化？
• 成本控制：每个任务的平均 token 消耗是多少？有没有因为过长上下文、循环调用、无效重试导致费用失控？
• 安全性：Agent 有没有可能被提示词注入？能不能保证它在权限边界内行动？敏感数据会不会被无意间写入 prompt 或日志？

这些问题的背后，是整个软件工程体系迁移到 AI 应用里的过程。Agent 不再只是一个模型调用的壳子，而是一个需要像后端服务一样被治理的系统组件。如果忽略这层，做几十个和做一个本质上没有区别。

所以，我判断一个人或一个团队的 Agent 实践处于哪个阶段，看的不是数量，而是是否遇到了系统性问题的挑战。如果你已经意识到“单个 Agent 能跑没用，还得能监控、能评测、能协作”，说明你已经进入第二阶段的门前。

3. 用四条线判断你的 Agent 实践到底处于哪个阶段

判断阶段不能靠感觉，建议用下面四条线来对照。每一条线都代表一个维度的工程成熟度。

3.1 可靠性：能不能重复拿到合格结果

这是最基础的一条线。所谓可靠性，是指你的 Agent 在相同条件下，多次运行得到合格结果的概率。大模型输出天然具有随机性，即便温度设为 0，也可能会因为模型版本、后处理逻辑、工具返回内容的变化而出现差异。所以，可靠性必须通过评测来确认，而不是靠“我试了几次都没问题”。

我一般会建议先建一个小型评测集，规模不用大，50 到 100 条有代表性的业务输入就够了。把每条输入喂给 Agent，记录输出，再人工或者用另一个模型判断输出是否合格。之后每次修改提示词、更换模型、调整工具，都要跑一遍评测集。跑完之后，你会得到一个可对比的数字，比如“这版 Agent 在评测集上的合格率是 92%”，而之前只有 88%。有了这个数字，你才能说“这版改动是变好还是变差”。

如果几十个 Agent 都没有对应的评测集，那它们的可靠性全凭运气。这也是为什么很多 Agent 在演示环境里看起来很好，到了真实数据上却不稳定的原因——你从来没有用真实数据分布去校验过它。

3.2 可维护性：模型升级、提示词改动、流程变更时是否容易调整

Agent 是活的系统，只要业务还在变、模型还在变，它就一定需要维护。我见过不少人，做完一个 Agent 之后提示词就再没动过，直到某天突然发现“它怎么变笨了”。其实不是变笨了，可能是底层模型悄悄换了版本，也可能是外部 API 的数据格式变了。

可维护性强的 Agent 应该具备这些特征：

• 提示词和代码分离，或者至少明确管理，不做“改代码里的一大段字符串”这种事。
• 工具函数的入参和出参有明确 schema，改动一个工具时不会影响其他逻辑。
• 配置项外部化，例如模型名称、温度、最大 token、超时时间都可以通过配置文件或环境变量修改。
• 有版本记录，能够回答“当前线上跑的是哪个版本的 Agent，提示词是什么”。
• 有回滚能力，当新版本表现变差时，能快速切回旧版本。

如果这些都没有，那你的几十个 Agent 其实是几十座“积木塔”，看着不少，但推倒重来非常容易。

3.3 可组装性：Agent 之间能否有序协作而不是各干各的

单 Agent 解决单点任务，多 Agent 解决的是复杂流程。但多 Agent 并不意味着“写十个 Agent 然后让它们自己聊”。它需要一套协作契约，包括任务拆分、交接协议、数据格式、错误反馈和终止条件。

可组装性的最低要求是：A Agent 的输出可以被 B Agent 的输入直接使用，而不需要人工清洗。如果再提升，就是能通过一个调度层，把多个 Agent 编排成一个完整的流程，支持条件分支、循环、超时、重试。最高级的状态，是你已经把 Agent 当成一种可插拔的“能力单元”，和普通微服务一样可以注册、发现、编排。

如果你只是把多个 Agent 写在同一个文件里，用 if-else 串联起来，那它仍然属于第一阶段——因为下一件事，当你需要把它拆出去独立部署或扩容时，又得重写。

3.4 可治理性：权限、审计、成本、安全是否纳入了设计

放到企业环境里，可治理性往往是最快暴露问题的维度。一个可以自主调用工具的 Agent，本质上是一个 “拥有一定权限的自动化账户”。它有可能读文件、发邮件、写数据库、调用支付接口。一旦出错，影响可能比普通后端服务更大，因为大模型的不可控性使得它可能做出超出预期的行为。

所以，在企业落地时，必须回答几个问题：

• Agent 被限制在哪些工具和数据集范围内？
• 它调用某个敏感操作前，需不需要人工审批？
• 它的完整执行链路有没有日志，能不能审计？
• 它的 prompt 有没有可能被用户注入恶意指令？
• 它的 token 消耗有没有预算上限，超出后会不会自动熔断？

这些问题在个人开发阶段很容易被忽略，因为你自己就是管理员、审计员和审批员。但一旦 Agent 给更多人用，以你的单人经验去覆盖所有边界案例，迟早会出问题。这也是我把可治理性当作阶段分界线的原因：不纳入治理的 Agent，永远是实验品。

4. 从“会做 Agent”到“能落地 Agent”的实操路径

如果上面四条线让你发现自己还在第一阶段，不要焦虑。绝大多数团队都需要先经历一个“做出一堆 Agent”的试错期。关键是下一步行动：开始从数量导向转变成系统导向。下面是我建议的实操路径。

4.1 第一步：先做一个“最小闭环”而不是铺开几十个

最常见的误区是想做大而全的系统：先规划十几个 Agent 角色，定义好它们之间怎么协作，然后一个月后交付一个“智能体平台”。实际执行时会发现，绝大多数时间花在调试 Agent 之间乱七八糟的通信上，最后交付的东西看起来像演示，但没法承受真实流量。

我更建议反过来：先选一条核心业务链路，用一个 Agent 把链路跑通。跑通的定义不是“成功跑了一次”，而是满足三点：

• 有输入数据。
• 有输出结果。
• 有日志和异常处理。

等这一个 Agent 稳定运行一段时间，比如一周或一个月，再开始想把它扩成两个 Agent。为什么要这么磨蹭？因为这一步的价值在于让你建立“Agent 是一个需要长期运行的系统”的感知。你会亲自遇到模型返回格式变化、工具调用失败、上下文累积变慢、依赖 API 限流等等问题。这些问题在一次性 demo 里根本遇不到，但在生产环境里它们才是主角。

做几十个 Agent 很容易，但把一个 Agent 做到被业务方真正依赖、连续工作一个月不出大问题，需要投入的精力是几十个 demo 的好几倍。先补上这种“生产级体验”，再来谈规模化。

4.2 第二步：把 Agent 当成软件工程的一部分来设计

如果 Agent 是代码，它就应该享受普通代码的待遇：版本控制、代码评审、单元测试、持续集成、部署流水线。其中最关键的是把 Agent 的可变部分（prompt、模型参数、外部工具）和不可变部分（业务逻辑、数据结构）解耦开。

以一个常见的“文档总结 Agent”为例：

• 不应把 prompt 嵌在代码里，而应放到单独的 prompt 模板文件或配置中心里。
• 不应允许 Agent 直接访问整个数据库，而应通过一个白名单 API 暴露必要的数据源。
• 不应每次重新计算摘要，而应缓存中间结果，减少 token 消耗。
• 不应在代码里硬编码模型名称，而应通过环境变量或配置项指定，方便后续切换或降级。

这样设计之后，你修改一个 Agent 的行为，不需要重新编译整个系统，也不需要担心“改了这里会不会影响别的脚本”。你只需要更新 prompt 模板，重新运行评测，然后发布新版本。

如果你已经有很多个零散的 Agent 脚本，也建议先做一次工程化整理：给每个 Agent 建一个标准目录结构，统一封装“模型调用、工具注册、输入输出解析、日志记录”的公共层，然后逐步把特殊逻辑抽离出来。这个过程会痛，但它能帮你从“写了 50 个脚本”变成“维护了一组可复用的 Agent 模块”。

4.3 第三步：建立 Agent 评估基线

前面提到了评测集，这里展开说。评估基线是 Agent 落地中最重要的“压舱石”。没有评估基线，你所有关于“Agent 效果变好”的结论，都可能只是幸存者偏差。

评估基线包含三部分：

• 输入样例集：覆盖正常输入、边界输入、异常输入、潜在攻击输入。正常输入保证核心能力，边界输入考验鲁棒性，异常输入考验错误处理，潜在攻击输入（例如 prompt 注入样例）考验安全性。
• 打分规则：每个输入对应一个或多个期望输出特征，判断标准可以是“是否包含关键信息”“JSON 是否可解析”“数字是否准确”“语气是否符合要求”等。打分规则要做到主观程度尽量低，至少两个标注者之间有一致性。
• 结果记录：每次评测要保存原始输出、模型版本、prompt 版本、工具版本、运行时间、消耗 token。这样你未来可以对比“上一次 92%，这次 89%，是因为改了 prompt 还是换了模型”。

建立评估基线后，你就可以把 Agent 的“感觉还行”变成“有数据支撑”。这也是你向业务方证明价值和发现回归问题的基础设施。没有这套设施，写一百个 Agent 也说不清它们到底有多可靠。

4.4 第四步：从单 Agent 到多 Agent 协作，先定协作契约

当你确定要把多个 Agent 串成一个复杂流程时，不要急着让它们“自由对话”。先定义协作契约，契约可以包括：

• 每个 Agent 的职责边界：它负责什么，不负责什么。
• 输入和输出 schema：每个 Agent 的输入应该长什么样，输出应该长什么样。
• 错误码和重试策略：A 调用 B 失败时，是重试还是降级？超时多久？
• 共享状态和上下文：哪些数据需要从一个 Agent 传给下一个，哪些信息不需要传。
• 权限边界：下游 Agent 能不能访问上游 Agent 未授权给它的数据。

如果只是随意拼装，很容易出现“A Agent 输出的字符串，B Agent 解析不了”“C Agent 无意识地把敏感信息透传给 D Agent”“循环调用导致 token 消耗爆炸”等工程灾难。

更优雅的设计是引入一个编排层（有人叫 Router、有人叫 Planner、有人叫 Orchestrator），它本身不承担具体业务，只负责把任务拆解、按顺序或按条件分发给对应 Agent，并汇总结果。这样的话，每个 Agent 依旧是相对独立的单元，你可以单独升级、单独测试、单独扩容。

5. 很容易被忽略的坑：记忆、上下文和安全性

进入更深层落地时，你会反复撞上三个让 Agent“看起来懂很多，但其实很脆弱”的坑。

5.1 记忆不是存聊天记录，而是状态管理

很多 Agent 框架会提供 memory 模块，可以存储历史消息、用户偏好、任务进度。但很多人会用错：把 memory 当成一个无限大的聊天记录袋子，全部塞给模型。这会导致两个问题：

• 上下文越长，token 成本越高，响应越慢。
• 早期消息会干扰模型当前决策，尤其是当早期信息与最新指令冲突时，模型容易迷惑。

真正的记忆不是“把所有东西存下来”，而是“选择性记住重要信息”。Agent 应该维护一个结构化状态，例如当前任务 ID、已完成步骤、用户偏好字段、待确认事项等。模型只需要读取与当前步骤相关的状态，而不是把全部历史都塞进 prompt。

设计记忆时，可以考虑分层：

• 短期记忆：当前会话内，保留最近几轮关键信息。
• 长期记忆：跨会话，但存储为结构化内容或向量索引，而不是原始对话。
• 业务状态记忆：任务进度、审批节点、中间结果，最好用专门的数据库或缓存管理。

你写几十个 Agent 时可能不需要考虑这些，因为它们任务简单。但一旦 Agent 要处理复杂长流程，记忆设计就会决定它是可控的自动化方案，还是一个黑盒。

5.2 上下文不是越长越好，而是需要裁剪和索引

和记忆相关但不同的一点，是 Agent 每次调用模型时的上下文窗口管理。许多人以为“模型能支持 128K 上下文，那就全给模型”，这既浪费资源又容易降低输出质量。模型对长上下文里的关键信息识别能力有上限，过度堆砌会导致关注重点漂移。

更好的方法是“先裁剪，再投喂”。例如，你想让 Agent 基于一份 100 页文档回答问题，正确的做法不是直接把全部文本塞给模型，而是先检索与问题相关的段落，再把检索结果送入上下文。这就需要引入搜索、分段、嵌入索引等机制。

在实践中，我会先给 Agent 一个工具叫“知识库检索”，内部使用向量相似度和关键词结合的方式返回 Top-K 相关片段。Agent 先调用这个工具，再基于返回的片段写答案。这比“把全文放进去让它自己找”更可控、更省 token、效果也更好。

所以，上下文工程并不是“堆提示词”，而是要学会管理信息密度：在合适的位置放合适的少量信息，让模型在有限的注意力里做最准确的判断。

5.3 安全与权限：Agent 越强，越要有边界

最后是安全。Agent 的能力越强，风险边界就越重要。概念上，Agent 安全至少有四层：

• 输入安全：用户输入的 prompt 可能包含恶意注入，试图让 Agent 执行非预期操作。需要对输入做过滤、转义或提示词隔离。
• 工具权限：Agent 不应该拥有它不需要的权限。如果一个 Agent 只负责查天气，就别把删除数据库的权限给它。
• 输出安全：Agent 生成的内容可能包含隐私信息、有害内容或版权风险，需要输出过滤和审计。
• 行为审计：记录 Agent 的决策路径、工具调用、输入输出快照，用于事后追踪和复盘。

在实际项目中，哪怕是最简单的 Agent，我也建议至少做到“敏感操作需要人工确认”。例如发邮件、删除文件、修改订单状态——这些动作不应该由模型自主完成，而应该由 Agent 生成操作请求，等待人工审批。你可以把审批做成一个简单的网页按钮或企业微信应用，甚至只是一条确认消息。这不会削减 Agent 的价值，反而会让它更容易被业务方接受，因为风险可控。

当你做了几十个 Agent 后，回头审视一下，有多少 Agent 调用了外部工具，且没有任何权限限制和日志记录？如果有，请优先补上。它们现在是你的效率工具，但也可能变成你的安全缺口。

6. 更底层的判断：AI 落地不是赌一个 Agent，而是建一套系统

6.1 Agent 的尽头不是“一个万能助手”，而是“一组专业执行体”

很多人想象中的 Agent 是一个什么都能干的超级助手，你跟它说一句话，它帮你把整个业务流程跑完。但现实是，大模型虽然博学，但它做跨界长链条任务时，失误率会累积。每一步都 90% 正确，十步之后正确率就只剩 35%。所以，追求“单个全能 Agent”在复杂业务里往往不如“一组专业 Agent + 一个调度器”可靠。

专业 Agent 只负责一个很窄的领域，例如“提取发票信息”“生成合同摘要”“检查代码规范”“翻译技术文档”。因为领域窄，它的提示词可以写得更精确，工具可以设计得更贴合，评测集更容易覆盖关键场景，运行也更可控。当每个 Agent 都是小而专的执行体时，组合起来的系统反而更可控——你可以对每个环节单独做质量看护，而不是赌整体一次成功。

这也是我为什么强调“几十个 Agent”并不是坏事的另一个原因：如果你把它们当成一组专业执行体来建设，而不是一堆临时脚本，那这几十个都是未来系统的零件。问题在于，你目前很可能只是把这些零件摆在一起，而没有装配成一个能协同工作的系统。

6.2 从几十个 Agent 到一套系统，需要补上哪些工程能力

如果要用一句话概括，那就是把“草稿代码”升级成“生产系统”。具体要补的工程能力包括：

• API 服务化：把每个 Agent 封装成独立服务，支持 HTTP 或消息队列调用，而不是只有脚本入口。
• 统一配置中心：所有 Agent 的 prompt 模板、模型参数、工具开关、权限配置，统一管理。
• 调度与编排：支持 DAG 或状态机式流程编排，使 Agent 之间按业务规则流转。
• 可观测性：为每次运行生成 trace，记录模型调用、工具调用、耗时、token 消耗、错误信息。
• 质量看护：把评估基线接进 CI/CD，每次发布新 Agent 或调整 prompt 都自动跑评测，防止回归。
• 成本计量：按 Agent、按任务、按部门统计 token 消耗和 API 费用，设置预算阈值。
• 安全治理：权限模型、审批流程、审计日志、数据脱敏、提示词注入防护。

这些能力，不是某个单一框架能全部替代的。优秀的 Agent 框架能帮你快速构建 Agent，但生产系统需要的往往是框架之外的胶水代码、运营规范和工程纪律。这也是为什么“做了几十个 Agent”和“完成 AI 落地”之间，还隔着一条很宽的河。

6.3 回到第一阶段：什么时候你才算真正走完第一阶段

第一阶段不是没有价值。它最主要的产出是“探索地图”：你知道哪些任务适合 Agent，哪些不适合；你知道模型擅长什么，不擅长什么；你知道自己的业务里有哪些流程可以自动化，有哪些需要人工介入。这些都是第二阶段建设时的宝贵前提。

所以，真正的问题不是“你做了多少个 Agent”，而是“做完这些 Agent 之后，你有没有沉淀出一套关于 Agent 落地的判断标准”。如果做了几十个之后，你开始意识到以下任一件事，都说明你正在迈向第二阶段：

• 开始关注评测集和回归测试。
• 开始给 Agent 补权限和日志。
• 开始把提示词和代码分离。
• 开始重视多 Agent 之间的协作契约。
• 开始问“这个 Agent 跑一个月会不会出问题”。
• 开始意识到“模型能力只是系统里的一环”。

这些意识的出现，比完成十倍数量的 Agent 更有价值。因为前者是积累，后者只是堆砌。

回到开头的场景。如果你已经做了几十个 Agent，却总觉得没真正落地，不用怀疑自己的投入，也不要去怀疑大模型能力。真正的差距，大概率在于你还没有把 Agent 从“有趣的工具”升级成“可靠的系统”。做 Agent 教会你如何调用模型，落地 Agent 才教会你如何治理不确定性。前者是起点，后者才是 AI 真正融入业务的地方。

下一步，请挑一个你做得最顺手、业务价值最高的 Agent，先给它补上评测、日志、权限和部署流水线。把一个跑成样板，再复制到其它 Agent 上。这个动作，比继续新增第几十一个 Agent 要有意义得多。