一位工程师正在重新设计他的自动化流程。不是让单个智能体更聪明，而是让整个系统更会协作。
从"超级员工"到"专业分工"
2023年初，大多数团队构建智能体的方式很简单：造一个"数字员工"，给它尽可能多的工具和能力，然后期待奇迹。这个思路听起来合理——能力越强，产出越多。
但Craig Oley在实践中发现了问题。当单个智能体被塞入十几种工具、数百行系统提示词和复杂的工作流逻辑时，它反而变得不可靠。推理链条太长，失败点太多，调试像在一团乱麻里找线头。
更隐蔽的成本是迭代速度。每次想调整某个功能，都要重新测试整个系统。一个看似小的改动，可能触发意想不到的连锁反应。
Oley的团队开始尝试另一种架构：把能力拆开。
他们不再追求"一个智能体搞定一切"，而是设计多个小型智能体，每个只负责极窄的任务。有的专门解析用户意图，有的只处理数据查询，有的纯做格式转换。智能体之间通过清晰的接口通信，像流水线工人传递零件。
这种"做减法"的思路，让单个智能体的系统提示词从数百行压缩到几十行。工具数量从十几个砍到两三个。每个模块的输入输出变得可预测，测试覆盖难度直线下降。
系统层面的"加法"
智能体变简单了，但系统整体变复杂了——这是刻意为之。
Oley把更多精力投入到智能体之间的编排层。这包括：任务路由逻辑（哪个请求该派给谁）、状态管理机制（上下文如何在模块间流转）、错误恢复策略（某个环节失败时如何优雅降级）。
关键洞察在这里：当智能体边界清晰时，系统可以动态组合它们。一个用户查询可能先经过意图识别智能体，再被拆成并行子任务派给不同执行器，最后由整合模块拼装结果。这种灵活性是"超级智能体"架构难以实现的。
编排层还引入了人工审核节点。不是每个输出都需人工检查，而是在高风险决策点设置"闸口"。这既保留了自动化的效率，又兜住了可靠性底线。
另一个被强化的部分是工具生态。Oley团队把常用能力封装成标准化工具，供多个智能体复用。工具本身有版本控制和性能监控，避免"每个智能体重造轮子"。
可靠性数据说话了
架构调整后的效果用数字说话。
端到端任务成功率从约60%提升到85%以上。更关键的是失败模式变了：以前失败是"黑箱崩溃"，现在失败是"某个模块超时，自动触发备用路径"。后者可诊断、可修复。
迭代周期也从数周缩短到数天。因为修改只影响局部模块，回归测试范围可控。新功能上线不再是一次"赌博"。
Oley注意到一个反直觉的现象：系统整体延迟没有因为"多跳通信"而增加。原因是小型智能体的推理成本更低，且并行执行抵消了协调开销。在某些场景下，新架构反而更快。
背后的设计哲学
这种"智能体做减法，系统做加法"的思路，本质上是对复杂性的重新分配。
单个智能体的推理能力是稀缺资源。把它用在最核心的判断上，而不是消耗在工具调用格式转换、多步骤状态跟踪这些"机械劳动"上。后者交给代码和系统架构解决，更便宜、更确定。
Oley把这种分工比作现代软件开发：没有人写"全能程序"，而是组合大量专用库和微服务。智能体系统正在走同样的进化路径。
这也解释了为什么提示词工程（Prompt Engineering）的热度在下降。当智能体职责收窄时，提示词自然变短变简单。复杂的逻辑被"外化"到系统层，用更工程化的方式管理。
给实践者的建议
Oley总结了几条可落地的经验。
第一，从用户旅程地图开始，而非技术能力清单。先画出"用户想要什么结果"，再倒推需要哪些处理环节。这能避免"为了用工具而用工具"的陷阱。
第二，为每个智能体写"岗位说明书"。明确它的输入格式、输出标准、绝对不能碰的边界。这份文档比提示词本身更重要，是团队协作的契约。
第三，投资可观测性。每个模块的延迟、成功率、成本都要可见。没有数据，优化就是盲打。
第四，保留人工介入的通道。完全自动化的目标可能遥远，但"自动化+人工兜底"是当下务实的选择。关键是设计好交接界面，让人工介入时上下文完整。
行业走向何方
这种架构思路正在影响工具链的演进。
智能体编排框架（如LangGraph、AutoGen）的采用率在上升。它们提供的不是"更强大的智能体"，而是"连接智能体的更好的管道"。云厂商也在强化相关能力，把状态管理、消息队列、弹性扩缩容这些基础设施打包成托管服务。
一个可能的趋势是：智能体本身趋于标准化、商品化，而差异化竞争发生在系统设计和领域知识的结合上。就像云计算时代，基础设施不是壁垒，怎么用基础设施解决特定问题才是。
Oley的实验还在继续。他最近关注的是如何让非技术同事也能参与系统调优——比如用自然语言描述路由规则，而非写代码。这可能会进一步降低迭代门槛。
如果你正在构建智能体系统，不妨审视一下：你的复杂度是集中在智能体内部，还是分布在系统架构中？前者可能让你陷入提示词调优的无尽深渊，后者或许才是规模化落地的正确姿势。
热门跟贴