从写代码到设计AI大脑
在宝软数字的技术团队中，CTO张工（化名）是一个传奇般的存在。十五年企业级软件架构经验，经手过从单体应用到分布式微服务的完整技术演进。"我写代码的年头比团队里最年轻的同事的年龄还长。"他笑着说。但就是这位老派架构师，在短短三年内带领一个不到十人的团队，从零搭建了一套包含35个AI Agent的企业智能体操作系统——EIOS。
这并非一个"拥抱新技术"的简单故事。在这背后，是一个资深工程师对AI时代的深度技术思考：什么样的架构才能让AI真正落地到企业场景？大模型的能力边界在哪里？Agent之间的协作应该如何设计？本次专访，CTO首次系统性地分享了EIOS背后的技术哲学和架构决策。
一、从传统架构到AI架构的认知跨越
"我做了十五年企业软件，养成了一个思维定式：一切皆可流程化。"CTO坦言，传统企业软件的架构思路是用代码精确描述业务流程的每一个分支、每一个状态转换。订单系统、审批流、报表引擎——所有这些系统本质上都是状态机。
但当2019年第一次接触Transformer模型时，他感到了一种"认知上的不适"。"大模型不是状态机。你给它一个输入，它给你一个输出，但中间的过程你无法精确控制。这对于一个习惯了确定性的架构师来说，是非常不舒服的。"
真正的认知突破来自一次失败的尝试。团队曾试图用传统的规则引擎来驱动AI客服，结果系统在边界场景下不断出错。"我们写了几百条规则，但真实世界的对话有无限种可能，规则永远追不上变化。"这次失败让他意识到：AI架构的核心不是"控制"，而是"引导"——给Agent设定目标和约束，让它自主探索执行路径，而不是用代码穷举所有可能。
二、EIOS的架构哲学：Agent即微服务
EIOS的核心架构决策可以概括为一句话：每个Agent都是一个独立部署、独立升级的微服务，通过统一的消息总线协作。这个决策并非追逐技术潮流，而是从实践中得出的必然结论。
"早期我们试图做一个大一统的Agent系统，一个模型处理所有任务。结果发现三个致命问题：第一，上下文窗口根本不够用；第二，不同任务的Prompt互相干扰；第三，一个Agent出问题，整个系统瘫痪。"
拆分之后，团队获得了三个关键收益：每个Agent可以针对特定领域进行Prompt和模型微调；Agent之间的依赖关系清晰可控，问题隔离变得简单；客户可以按需选择Agent组合，不会为用不到的能力买单。
Agent之间的通信采用了标准化的消息协议。"我们不希望Agent之间直接调用对方的内部API，那样会产生紧耦合。所有Agent只和消息总线交互，发消息和收消息。这听起来像是回到了SOA时代，但事实证明在AI场景下这恰恰是最合适的模式。"
三、35个Agent的分类与协作设计
35个Agent被系统性分为四大类：客户交互类（9个）负责对话理解、意图识别、多渠道接入等；流程自动化类（11个）负责订单处理、审批流转、库存管理等；数据分析类（8个）负责报表生成、异常检测、趋势预测等；知识管理类（7个）负责文档理解、知识抽取、智能搜索等。
"分类不是拍脑袋的。我们分析了200多个客户的实际业务场景，提取出高频出现的需求模式，然后才确定每个Agent的职责边界。"CTO强调，Agent设计的黄金法则是"一个Agent只做一件事，但做到极致"。
Agent之间的协作遵循一个精心设计的编排协议。当一个用户请求到达系统时，路由Agent首先判断意图，然后根据意图类型将任务分派给一个或多个专业Agent。如果需要多个Agent协作，则由编排Agent负责协调执行顺序、传递中间结果、处理异常情况。
"编排Agent是我们技术含量最高的组件之一。它需要理解任务之间的依赖关系、评估每个子Agent的执行能力、并在出错时做出合理的回退决策。这本质上是一个小型规划系统。"
四、大模型选型与成本控制的实战经验
"选模型这件事，我们交过不少学费。"CTO回忆道，团队早期过度迷信最强模型，所有Agent都用当时最贵的模型。"结果月底看账单的时候吓了一跳——一天的AI调用费用抵得上一个员工的月薪。"
经过近一年的优化，团队总结了一套模型选型策略：任务分级 + 模型匹配。简单任务（如关键词提取、格式校验）使用轻量模型；中等任务（如意图分类、文档摘要）使用中等模型；复杂推理任务（如多步规划、长文档理解）才使用最强模型。
"这个策略让我们的AI调用成本降低了约70%，而任务质量几乎没有下降。"他分享了一个具体数据：在客服场景中，约80%的对话轮次只需要轻量或中等模型即可处理，只有20%的复杂场景需要强模型介入。
此外，团队还建立了严格的结果缓存和相似请求去重机制。"同一个客户的同一个问题不应该两次调用模型。我们做了语义级别的缓存：当新请求和历史请求的语义相似度超过阈值时，直接复用历史结果。"
五、踩过最大的坑：Prompt工程的幻觉问题
当被问及技术层面最大的挑战时，CTO几乎没有犹豫："Prompt工程的可靠性问题。这是一个被严重低估的技术难点。"
他详细解释了问题的本质：同样的Prompt，在不同的模型版本、不同的输入上下文下，可能产生截然不同的输出。这在企业场景中是致命的——客户无法接受一个"有时候好用有时候不好用"的系统。
"很多人以为Prompt工程就是写一段文字。实际上，真正的Prompt工程是一门系统性的学科：需要版本管理、回归测试、效果评估、灰度发布。我们为每个核心Agent维护了50到200组测试用例，每次修改Prompt都要跑全量回归测试。这跟传统软件开发的质量保障没有本质区别。"
团队还开发了内部的Prompt评估框架，能够自动评估Agent输出的准确率、完整性和一致性。"没有自动化评估，光靠人工Review根本无法跟上迭代速度。"
六、给技术人的建议：AI时代需要什么样的工程师
采访最后，CTO分享了他对AI时代工程师能力模型的思考。"纯粹的代码编写能力会越来越贬值。未来真正稀缺的工程师，是那些能理解业务、设计系统、并善用AI工具的人。"
他提出了AI时代工程师的四个核心能力：系统设计能力——能把复杂的业务需求拆解为可执行的Agent协作流程；评估判断能力——能客观评估AI输出的质量，知道什么时候该信任模型、什么时候该加规则约束；实验能力——能设计严谨的实验来验证假设，而不是凭直觉做决策；业务理解能力——能快速深入一个行业，理解其核心痛点和数据特征。
"我不是让你扔掉代码，而是让你把视野从'写代码'提升到'设计系统'。代码仍然是实现手段，但它不再是稀缺资源了。稀缺的是判断力和设计力。"