有毒关系 💔：当你的代理产生幻觉

Source: Dev.to

问题概述

爱情是盲目的，但在生产环境中，盲目信任是致命的架构缺陷。
这个情人节，别人谈论化学反应时，我们来聊聊状态分歧。你技术栈中最有毒的关系是未受监管的主代理（Lead Agent）与专门的工作者（Worker）之间的关系。缺乏严格的验证，代理会以最糟糕的方式“抢话”：产生根本不存在的上下文。

在自治系统中，可靠性不是靠更好的提示，而是靠更好的边界。允许代理在没有验证层的情况下更新全局状态，等同于让一个非确定性过程改写你的真相来源。

Actor‑Critic 模式

我们不采用线性指令链，而是部署 Actor‑Critic 模式。它将创造性的问题求解过程（Actor）与严格的验证过程（Critic）分离。

• Actor 提出解决方案。
• Critic 在不同的约束和工具集合下，对工作进行签署，只有通过验证后才会提交到状态中。

人类不再是每个任务的瓶颈，而是关键操作背后的高完整性闸门。

示意图

graph TD
    A[User Request] --> B{Lead Orchestrator}
    B --> C[Actor Agent: Generation]
    C --> D[Proposed Action/Code]
    D --> E{Critic Agent: Validation}
    E -- Rejected: Hallucination Detected --> C
    E -- Approved: Schema Validated --> F[Human-in-the-Loop Gate]
    F -- Approved --> G[Production Execution]
    F -- Denied --> B
    G --> H[Update Global State]

回声室效应

如果 Actor Agent 出错，而 Orchestrator 将其当作事实接受，那么图中的每一步都建立在谎言之上。我们通过确保 Critic 能访问 独立的真相来源（例如只读数据库或静态文档库，Actor 无法影响）来打破这种局面。

当流程到达 Human‑in‑the‑Loop 闸门时，代理之间的“关系”已经过滤掉噪声。人类不再去修复基本的逻辑错误，而是提供高层次的战略批准。

Actor‑Critic 编排的优势

• 减少 Token 浪费 – 及早捕获错误，防止基于错误前提的昂贵、长时间循环。
• 可审计性 – 每一次 Actor 与 Critic 的分歧都会被记录，清晰映射出需要改进的提示或工具。
• 治理 – 可以用更便宜的模型替换 Actor，同时保留高端模型作为 Critic，以维持质量控制。

结论

别再爱上你的第一个原型。构建一个能够自我质疑的编排层。

您想让我为您最常见的代理失效模式设计一个具体的 Critic 架构吗？