作者:WiseAgent小而美智能体架构师
在过去的一年里，我参与了不少企业的 AI 落地咨询。最常听到的一句话就是：“我们要不仅要做一个客服，还要让它能查库存、能下单、能写周报，最好还能陪客户聊聊人生”。老板们想要的是一个无所不能的“超级员工” (General Purpose Agent)，就像钢铁侠的 Jarvis。
但作为负责系统稳定性的工程师，我必须直言：在企业级生产环境中，追求“通用全能”通常是一场灾难的开始。如果你把所有业务逻辑、几十个工具（Tools）、几万字的知识库都塞进一个 Prompt，试图用一个 GPT-4 搞定一切，你得到的不是 Jarvis，而是一个反应迟钝、成本高昂、且极难调试的“黑盒怪物”。
在我的工程实践中，“小 Agent + 明确边界” (Small Agents + Defined Boundaries)才是目前技术条件下，企业落地的最优解。这不仅仅是 AI 问题，本质上是软件工程中的“解耦”思想在 AI 时代的延续。
一、 通用 Agent 的“单体地狱”
在传统的软件开发中，我们早就抛弃了“单体巨石应用”（Monolith），转向了微服务架构。但在 AI 开发中，很多人却在走回头路。试图构建一个通用 Agent，在工程上会面临三个无法解决的死结：
上下文污染（Context Pollution）：当你把“请假流程”和“财务报销”的规则都塞进同一个 Context Window 时，模型很容易混淆。比如用户问“我要报销”，模型可能会错误地调用“请假审批”的工具。干扰项越多，推理精度越低，这是概率模型的铁律。
调试的噩梦：当你的 Agent 出现幻觉时，你根本不知道是哪一部分 Prompt 出了问题。你为了修复“查库存”的 Bug 修改了 System Prompt，结果第二天发现“写周报”的功能崩了。这就是典型的回归测试（Regression）灾难。
成本与延迟：杀鸡焉用牛刀？处理一个简单的“重置密码”请求，真的需要带着几千 tokens 的“公司战略文档”去调用一次昂贵的 GPT-4 吗？这在 ROI（投入产出比）上是算不过账的。
二、 小 Agent：AI 时代的“微服务”
我的架构原则很简单：单一职责原则（Single Responsibility Principle）。一个 Agent 只做一件事，并且把它做到极致。在我的系统中，所谓的“AI 助理”其实不是一个模型，而是一个Agent 集群，由一个极简的路由层（Router）进行分发：
Agent A（请假专员）：只挂载“提交请假单”和“查询假期余额”两个工具。它的 Prompt 只有 500 tokens，甚至可以用廉价的 GPT-3.5 或微调过的 7B 模型。
Agent B（知识库问答）：只负责 RAG 检索。它不知道怎么操作数据库，只负责读文档。
Agent C（数据分析师）：这是一个昂贵的 GPT-4 Agent，专门负责写 SQL 和生成图表，只有在用户真的需要分析数据时才会被唤醒。
这样做的好处是显而易见的：
隔离性：Agent A 崩了，不影响 Agent B。
可观测性：哪个环节出错，看日志一目了然。
灵活性：不同的 Agent 可以使用不同的模型（Model Agnostic）。简单的任务用小模型，复杂的任务用大模型。
三、 明确边界：知道“不能做什么”比“能做什么”更重要
在 POC（概念验证）阶段，大家关注的是 Agent能做什么（Upside）；但在上线阶段，我更关注它不能做什么（Downside）。通用 Agent 最大的风险在于边界模糊。它太想取悦用户了，以至于在不知道答案时倾向于胡编乱造。对于“小 Agent”，我们可以划定非常硬的工程边界：
白名单机制Agent A 只能调用 API
leave_submit，绝对没有权限调用database_delete。这是代码层面的物理隔离，而不是靠 Prompt 里的“请不要删除数据”这种软约束。确定性的“不知道”因为 Agent A 的职责很窄，当用户问它“明天的股价是多少”时，它不需要去检索互联网，它的 Prompt 里写得很清楚：“如果问题与请假无关，直接回复：这超出了我的能力范围。”在企业服务中，诚实的拒绝远比错误的建议有价值。
状态机兜底每个小 Agent 内部都应该有一个有限状态机（FSM）。如果 Agent A 处于“等待审批”状态，无论用户说什么，它都不能跳转到“新建申请”状态。这种逻辑必须写死在代码里。
四、 编排（Orchestration）即业务
有人会问：“拆得这么散，怎么协同”？这正是中控层（Orchestrator）的职责。
在这个架构中，核心壁垒不再是 Prompt 写得有多花哨，而是工作流（Workflow）的编排能力。
用户输入 ->Router识别意图 -> 分发给Agent A。
Agent A完成任务，返回结构化数据 ->Router判断是否需要Agent B继续处理。
这种“代码逻辑为主，模型推理为辅”的架构，将不确定的 AI 能力封装在确定的业务流程中。我们实际上是在用确定性的代码（Python/Java）去串联一个个概率性的模块（LLM）。这才是符合工程理性的做法。
去魅与回归
企业不需要一个会写诗、会编程、会聊天的“数字爱因斯坦”。企业需要的是一个守纪律、不犯错、可追溯的数字员工。从“通用 Agent”转向“小 Agent + 明确边界”，本质上是从“玩票”心态回归到“工程”心态。
通用 Agent是把复杂性藏在 Prompt 里，祈祷模型能理解。
小 Agent是把复杂性拆解到架构里，由工程师来掌控。
作为技术负责人，我宁愿管理一支由 10 个专业工种组成的流水线队伍，也不敢把公司的命运交给一个喜怒无常的“全能天才”。控制熵增，降低不确定性，这才是 AI 工程化的终极目标。
