从混乱到清晰：打造可靠企业多代理系统的五个关键教训

当一家中型科技公司找上 Zokforce，希望我们协助设计一套由多个 AI 代理驱动的人资领域人才管理系统时，我们以为自己很清楚前方的挑战。从商业角度来看，这个案子很有说服力：自动化招募流程、简化新人到职作业、减少人工的人资作业。技术做法看起来也很直接：为每个领域部署专责代理，通过中央调度代理加以协调，粗重的工作就交给 AI。

接下来的六个月，我们反复试错，也换来得之不易的洞见，从根本改变了我们开发多代理系统的方式。本文分享这段历程：这不是一则数据漂亮、包装精美的成功故事，而是打造复杂 AI 系统时真实而混乱的样貌、我们犯过的错，以及在克服这些挑战的过程中学到的教训。

充满希望的开端

初始架构在纸上看起来相当优雅。我们设计了五个彼此协作的专责代理：

招募代理职缺刊登 · 履历筛选

调度代理所有代理都通过它进行协调

薪酬代理薪资 · 福利

到职代理文档处理 · 系统权限

绩效代理目标设置 · 考核评估

计划：

• 招募代理：处理职缺刊登、筛选履历、安排面试
• 到职代理：协调文档处理、系统权限开通与训练时程
• 薪酬福利代理：计算薪资、管理福利、产生报表
• 绩效管理代理：设置目标、管理考核流程、收集反馈
• 调度代理：分派任务、监控流程、解决冲突

每个代理在自己的领域内独立运作，由调度代理确保交接顺畅。客户的人资团队可以专注于策略性工作，例行作业则交给代理处理。

接着，我们试着把它部署上线。

教训 1：规格陷阱——当「清楚」的指示其实不够清楚

问题出在哪里

查看运行日志后，我们发现一个根本问题：我们的指示模棱两可。我们要求代理「依据职缺要求筛选履历，找出合格的候选人」。听起来很清楚，对吧？但我们并没有定义：

• 「合格」以可衡量的标准来说代表什么
• 如何处理边界案例（例如：经验略低于要求、但技能出众的候选人）
• 职缺要求互相矛盾时该怎么办（要求 10 年经验，却只给新手薪资）
• 何时该把不确定的决策往上呈报，何时可以自行决定

代理用自己的解读填补了这些空白，而这些解读在每次运行时都会不可预期地改变。

更深层的问题

这正是研究所称的规格错误，也是多代理系统中最常见的失败模式。问题不在于 LLM 看不懂指示，而在于它们非常擅长找出我们从未想过、却同样说得通的解读。

其中一次令人印象特别深刻的失败，发生在我们要求到职代理「为新进员工创建账号」时。它替第一位员工在所有系统中都创建了账号；替下一位只开通了电子邮件；替第三位则在人资数据库中建立了重复的账号。同一条指示，三种不同解读，毫无一致性可言。

我们学到的事

Evaluate each resume against the following criteria:

1. Required qualifications (must have ALL):
   - [List with exact matching rules]
   
2. Preferred qualifications (weight each):
   - [List with scoring rubric]
   
3. Disqualifying factors (immediate rejection):
   - [Explicit list]

For candidates scoring 80-100: Auto-advance
For candidates scoring 60-79: Flag for human review
For candidates scoring below 60: Auto-reject with reason code

If any criterion is ambiguous or missing, mark as 
"INSUFFICIENT_INFO" and request clarification.

即便如此还是不够。我们必须加入限制条件验证：代理在处理之前，必须先确认已取得所有必要信息，并以我们能用程序验证的结构化格式输出评分结果。

教训 2：协调恶梦——当代理之间无法沟通

问题出在哪里

我们来来回回花了好几天修正通信协定。我们在消息中加入更多字段，接着薪酬代理抱怨它需要的是另一组字段。我们又把那些字段加上去，然后绩效管理代理又需要另一种数据结构。

不到两周，我们就有了五种不同的消息格式，完全没有互通性，而且代理一收到预期外的输入就干脆停止回应。

更深层的问题

2 个代理 = 1 条路径

4 个代理 = 6 条路径

5 个代理 = 10 条路径

协调复杂度呈平方级成长每一次交互都可能造成沟通误解、数据遗失或格式不符。

这就是困扰多代理部署的协调失败问题。每个代理单独来看功能都正确，但整体行为却一片混乱。问题会呈指数级扩大：2 个代理 = 1 个潜在协调点，4 个代理 = 6 个潜在协调点，5 个代理（我们的系统）= 10 个潜在协调点。

我们学到的事

{
  "message_id": "uuid",
  "conversation_id": "uuid",
  "sender_agent": "recruitment",
  "receiver_agent": "onboarding",
  "message_type": "TASK_DELEGATION",
  "timestamp": "ISO8601",
  "payload": {
    "action": "initiate_onboarding",
    "entity_id": "emp_12345",
    "entity_type": "employee",
    "required_data": {
      "employee_info": {...},
      "employment_details": {...}
    }
  },
  "callback_required": true,
  "callback_timeout_seconds": 300
}

更重要的是，我们落实了严格的接口合约。每个代理都会公开一份 schema，明确定义它需要哪些数据、会输出哪些数据。调度代理在传递每则消息之前，都会依据这些合约进行验证。

如果某个代理试图送出不完整的数据，消息会在边界就被退回，而不是等到接收端代理已经尝试处理、又莫名其妙地失败之后。

教训 3：记忆碎片化问题——当上下文消失

问题出在哪里

深入调查后，我们发现代理其实根本记不得笔电已经订购：它为了回应第一个问题而提取了这项信息、产生回复，然后立刻就忘了。被问到后续问题时，它完全没有上一轮交互的上下文。

这并非个案。代理经常「忘记」自己做过的决定、与刚提供的信息自相矛盾，或是索取早已收到的数据。

更深层的问题

这就是上下文碎片化问题：每个代理各自维护短暂的工作记忆，而对话一往下进行，这些记忆就消失了。在横跨数小时甚至数天的企业流程中，这会造成根本性的可靠度问题。

更糟的是，当多个代理需要协同作业时，它们对情况各自只掌握不同的片段。招募代理知道候选人谈到了更高的薪资，到职代理却不知道，薪酬代理则按照标准的录取金额处理。三个代理，三种不同的现实，换来一位非常愤怒的新进员工。

我们学到的事

第 1 层工作阶段记忆短暂

30 分钟

范围

仅限目前对话

保存

Redis 缓存（TTL 30 分钟）

目的

支持自然的多轮对话

第 2 层任务记忆持久

一个业务流程

范围

一个业务流程的完整期间

保存

PostgreSQL，以 workflow_id 为键

目的

在代理交接之间维持连续性

第 3 层共享知识库永久

全时段

范围

所有代理、全时段

保存

向量数据库 + 结构化数据

目的

提供一致的事实基准

每次代理行动前都注入上下文，确保一致性。

第 1 层：工作阶段记忆（短暂）——仅限目前对话，使用 TTL 为 30 分钟的 Redis 缓存，支持自然的多轮对话

第 2 层：任务记忆（持久）——涵盖一个业务流程的完整期间，使用以 workflow_id 为键的 PostgreSQL，在代理交接之间维持连续性

第 3 层：共享知识库（永久）——所有代理、所有时间，向量数据库 + 结构化数据，提供一致的事实基准

关键在于，我们加入了对话历史注入：在任何代理处理请求之前，调度代理都会提供先前交互中所有相关的完整上下文，而不只是当下的查询。

教训 4：验证缺口——当没有人检查成果

问题出在哪里

一阵恐慌随之而来。我们展开调查，理出了事件的来龙去脉：

1. 绩效管理代理建议依绩效调薪（正确：3-5%）
2. 薪酬代理处理调薪（错误：把 3-5% 解读成 300-500%）
3. 薪资系统照单执行（尽责地：按代理指定的金额发薪）

没有人发现这个错误。每个代理都假设上一个代理已正确完成工作。系统没有验证层、没有合理性检查，也没有判断「这个结果合理吗？」的能力。

这绝不是唯一的验证失误。我们还发现：

• 到职代理建立的用户账号，权限明显有误
• 招募代理寄面试邀请给早已被淘汰的候选人
• 绩效管理代理用错误的公式计算绩效分数

更深层的问题

补上验证缺口，往往是团队最后才做的事。大家以为只要每个代理都「够聪明」，系统就能正常运作。这种想法错得很危险。

问题在于 LLM 是信心机器：即使输出毫无道理，它们仍会以高度信心产生结果。在多代理系统中，一个代理信心满满的错误，会成为下一个代理信心满满的输入，形成没有人质疑的连锁失败。

我们学到的事

各层拦下的错误比例

第 1 层结构验证约 40%Schema 验证 · 类型检查 · 缺漏字段侦测。低成本、自动化，拦下格式与结构错误。

第 2 层业务规则验证约 35%限制条件检查 · 范围验证 · 逻辑验证。例如：薪资变动超过 20%、不可能的日期。

第 3 层跨代理一致性约 15%调度代理维护不变条件 · 状态核对。确保各代理的相关决策保持一致。

第 4 层人工审查约 10%低信心决策 · 边界案例 · 静默失败。代理自评信心分数，分数过低即触发审查。

验证为强制且具阻挡性未通过就不能继续。

第 1 层：结构验证——每个代理的输出都会依据 schema 检查。类型错误、缺漏字段、格式不正确的数据都会立即被拦下（拦下约 40% 的错误）

第 2 层：业务规则验证——自动检查是否违反业务逻辑。例如：薪资变动超过 20%、重复创建账号、不可能的日期（拦下约 35% 的错误）

第 3 层：跨代理一致性检查——调度代理维护跨代理的不变条件。如果招募代理将某人标记为「已录用」，到职代理就必须有对应的任务（拦下约 15% 的错误）

第 4 层：依信心分数进行人工审查——代理自行回报信心分数，低信心的决策会自动转交人工审查（拦下边界案例并防止静默失败，约 10% 的错误）

关键在于，我们让验证成为强制且具阻挡性的步骤：验证未通过，代理就不能进行下一步。

教训 5：复杂度爆炸——当代理越多反而越糟

问题出在哪里

每添加一个代理，系统复杂度都呈指数级增加：

• 代理越多 = 协调点越多
• 协调越多 = 失败模式越多
• 失败模式越多 = 调试时间越长
• 调试越多 = 开发越慢

到了第七个代理，我们把 80% 的时间花在排除协调问题上，只有 20% 用于实际功能开发。更糟的是，系统变得极其复杂，连我们自己都无法可靠地预测它的行为。

压垮骆驼的最后一根稻草，是合规代理与薪酬代理陷入了无穷循环：合规代理把一笔薪资计算标记为可能不合规，薪酬代理重新计算，合规代理又标记新的计算结果，如此无止境地重复。系统陷入死结长达 47 分钟，最后才因逾时而终止。

更深层的问题

这就是组合爆炸问题。协调成本会随代理数量呈平方级成长：

• 四个代理的系统有 6 条协调路径
• 七个代理的系统有 21 条协调路径
• 十个代理的系统有 45 条协调路径

研究也证实了这个残酷的事实：增加更多代理，往往反而降低性能。协调的额外负担超过了专业分工带来的好处。

我们学到的事

决策 1：合并代理

• 把合规检查并入薪酬代理（同一领域）
• 把学习发展并入绩效管理（共用流程）
• 从七个代理减回五个

决策 2：限制代理之间的直接沟通

• 改用中心辐射式（hub-and-spoke）架构，而非网状架构
• 所有沟通都经由调度代理
• 消除代理之间的相互依赖

决策 3：单一代理优先原则

• 添加代理之前，我们会先问：「现有代理能否通过更好的提示来处理这件事？」
• 只有在单一代理方案明显失败时，才会添加代理

结果呢？系统可靠度大幅提升。回应时间缩短，调试变得可以掌控，团队终于能真正理解并推断系统的行为。

全局视角：我们希望早点知道的事

回顾过去，这些教训有一条共同的主线：多代理系统之所以失败，不是因为 AI 的极限，而是因为架构与设计上的决策。

我们遇到的失败，与业界研究的结果高度吻合：

• 32% 规格错误
• 28% 协调失败
• 24% 验证缺口
• 再加上系统规模扩大时层层累积的复杂度

如果重来，我们会这样做：

我们现在的进展

六个月后，这套人资系统已在正式环境中运作。它并不完美，仍需持续监控与调整，但已经可靠到人资团队愿意把真实流程交给它处理。

更重要的是，我们已将这些教训内化，运用在未来的多代理项目中。如今我们会以适度的审慎态度面对这类项目：从简单开始，只有在有明确效益支持时才增加复杂度。

成功需要的不只是强大的 AI 模型，还需要深思熟虑的系统设计、严谨的测试，以及在复杂度失控时勇于简化的谦逊。