人工审核正在成为 AI 系统的发展瓶颈
在大模型应用落地过程中，有一个被忽视的结构性矛盾：当 AI 代理（Agent）需要做出高风险决策时，行业主流做法是引入"人工审核"（Human-in-the-Loop，HITL）。但这种做法在低频、小规模的开发测试阶段尚可勉强维持，一旦进入生产环境——数十个代理并发运行、每小时产生数百次决策——人工审核立刻成为系统吞吐量的致命瓶颈。
问题并不在于人类反应迟钝，而是治理架构本身存在技术债务：大量二元决策被推入人工队列，审核质量随积压量增加而急剧下降。操作人员开始跳过审核&查验细节，对可疑决策直接点击"批准"，只因为积压实在太多、会议即将开始、且"还没出过大事"。这就是告警疲劳（alert fatigue）的典型表现：治理退化成了手动流水线管理。
Tyler Akidau 在《后人类时代：我们都在构建 Agent，却没人构建 HR》中尖锐地指出：整个行业对代理的"能力"投入巨大，但对约束、授权与问责的基础设施建设却严重不足。
scalable AI 的真正含义不是"雇更多审核员盯着更多机器人"，而是彻底改变治理模型——将人工审核从必经之路变为最后防线。
从"能力"到"责任"：两种不同的代理设计思路
当前企业 AI 的主流思路只问一个问题：这个代理能做什么？ 它有哪些工具？能够调用哪些 API？——这是"能力导向"的框架，自然且直观，但在生产级高风险系统中，这个框架从根上就错了。
类比组织设计中的"角色"概念：一个角色（Role）是稳定且被明确分配的。类似于传统软件中的 RBAC（基于角色的访问控制），角色定义的是某人在任何时候被授权执行的操作，而非其当前正在执行的任务的具体描述。这种边界约束是硬性的、不受大模型"发挥空间"影响的。
"能力"描述的是功能边界，"责任"描述的是授权边界。 两者在生产环境中差距巨大，以下列举三个典型行业场景的对比：
- 金融交易：能力 = "可以执行股票交易"；责任 = "每笔订单上限 5 万美元，仅限高流动性股票，单日最大回撤 2%"
- 医疗运营：能力 = "可以重新安排患者预约"；责任 = "仅可重新预约非关键门诊，且窗口不超过 14 天，严格避免专科医生重复排班"
- 供应链：能力 = "可以重新规划货运路线"；责任 = "仅可转运非危险货物，SLA 违约金预算上限 5000 美元"
在真实生产场景中，代理一旦涉及资金流动、医疗记录或实体物流，上述两个描述之间的差距，就是 Demo 与生产部署之间的距离。
当前行业通常用 Prompt 来弥合这个差距——给大模型一个 API 密钥，告诉它"注意仓位管理"，然后寄希望于对齐（alignment）能在对抗性输入、异常市场条件或边缘案例的诱惑下依然生效。这种方式在低风险场景或许勉强可行，但在高风险、真实世界副作用明显的系统中，根本不是合格的控制面。
责任导向智能体：借鉴 Actor 模型的设计思路
这个"能力 vs 责任"的区分并非新创。分布式系统在几十年前就解决了类似难题。
Carl Hewitt 于 1973 年提出的 Actor 模型提供了一个有用的基础：Actor 是一个独立的计算实体，拥有自己的状态、行为和消息接口；Actor 之间不共享状态，仅通过消息传递通信；关键约束是 Actor 的行为是受限的——由它接受哪些消息决定，而非一个开放的能力集合。
责任导向智能体（Responsibility-Oriented Agent，ROA） 并非发明新的分布式系统原语，而是围绕不可预测的大模型核心，将成熟模式组合起来：受限行为体（bounded actors）、RBAC 式授权信封（authority envelope）、审计日志（audit trail）和执行边界验证（execution-boundary validation）。
严格来说，ROA 更接近一个"决策参与者"而非完整计算 Actor：它维护自身内部状态，但不直接修改外部世界。在一个稳定的角色（Role）、固定的任务（Mission）和机器可执行的合约（Contract）约束下，ROA 接收业务事件，在相关上下文中进行推理，并向运行时（Runtime）提交 PolicyProposal 由其进行验证。
ROA 代理的核心职责是认知层面的——解释现状、构建意图，而非执行操作。与传统 Actor 不同，ROA 代理遵循严格的责任分离原则：凭证存在于代理可及范围之外，不打开到外部系统的直接执行通道，也不自行写入状态。代理可以通过工具收集上下文（在沙箱内只读查询知识库等），但所有状态变更操作都需经过下游的确定性验证和执行门控。唯一可归因于代理的状态变更步骤是 emitpolicyproposal——这是一种结构化的、带类型的声明，表示代理希望系统执行某项操作。ROA 负责塑造意图的形式，而 Runtime 决定该意图是否被允许转化为行动。
这一分离是整个架构最重要的属性。五个工程支柱共同定义了它在实践中的含义——每个支柱针对推理–执行边界的不同失效模式——它们共同将 LLM 从概率工具转化为可治理、可问责的系统组件。
为便于理解，以伦敦商业市场的承保代理接收房产提交为例：代理读取文档后生成解释性叙述（Explain），随后发出一份报价的政策建议（PolicyProposal）。但房产价值为 1500 万英镑，而合同授权上限为 1000 万英镑。建议进入内核后，Runtime 确定性解析 YAML 合同，发现授权不足并拒绝执行，同时将流程转换为升级（ESCALATED）状态。此时，高级核保人无需审阅每一笔 200 万英镑的提交，只会被针对这一特定的 1500 万英镑异常情况通知。这就是一个决策中"人在环"（Human-Over-The-Loop）的完整体现。
工程支柱一：责任契约——权限编码于代码
如果说角色（Role）定义了代理可处理的决策类型，那么责任契约（Responsibility Contract）则定义了这些权限的硬边界。代理的权限范围不是提示词，而是一份版本化的、机器可读的合同，注册在 Agent Registry（内核的代理身份单一真相源）中。这里有一个关键属性：提示词只是建议，代码才是执行。一条"每笔交易不超过 10000 美元"的提示词，可以被足够"有创意"的模型重新解读，或被精心设计的提示词注入覆盖。而 maxordersize_usd: 10000.0 这样的合同字段，由确定性运行时代码验证，从根本上比自然语言指令更难绕过。在参考架构中，合同是带外部署的——代理不自行注册，也不能读写或修改自己的合同。
这一设计还有一个容易被忽视的二阶效应：角色定义自动限定了代理所需的数据上下文范围。例如，如果承保代理的合同限制为 HOMESTD 和 HOMEPLUS 险种类型，以及 LOW 和 MEDIUM 风险层级，那么 Context Compiler（负责在每次推理调用前组装代理工作快照的组件）只需提供与这些维度相关的信号。商业财产市场数据、被排除风险层级的洪泛区统计、其他产品线的监督&管理数据等都完全不在范围内——上下文被合同确定性收窄了。
这对 LLM 工程有实际意义：实践中，模型往往在工作上下文扩大时变得不可靠，这包括从业者所说的 "Lost in the Middle"（迷失在中间）现象。紧密限定的角色不仅是治理上的便利，更是保持代理工作上下文足够小以便可靠推理的架构机制。相比之下，被赋予不受约束上下文的通用代理，比在定义域内运行的契约绑定代理更容易性能下降。
在保险承保示例中，责任契约可配置如下：
agents:
- agent_id: "underwriter_agent"
version: "1.0.0"
created_by: "[email protected]"
created_at: "2025-02-17T10:00:00Z"
mission: |
You are an insurance underwriter. Analyze the client application and propose a policy. Base premium on Total Insured Value (TiV) at ~2% of TiV, capped at max_tiv. NEVER propose for Fireworks or CryptoMining industries - these are prohibited.
contract:
role: EXECUTOR
max_tiv: 3000000
prohibited_industries: ["Fireworks", "CryptoMining"]
escalate_on_uncertainty: 0.65工程支柱二：任务（Mission）——北极星
Mission 在运行时不可变。如果 Contract 定义了代理可以做什么，Mission 则定义了它在该边界内试图优化什么。这一区别具有重要的操作意义：Contract 回答 "May" 的问题，Mission 回答 "Should" 的问题。两个代理可以共享相同的权限范围，只要都保持在同一硬边界内，就能针对不同的业务结果进行优化。
在 ROA 架构中，Mission 是部署产物，有两个表面：供代理内部推理使用的人类可读的 mission_statement，以及供 Runtime 强制执行完整性的机器可验证的 mission_context_hash。
missionstatement: "Minimize SLA penalties in logistics rerouting. Prioritize low-cost carriers." missioncontexthash: "sha256:a3f9b2c1..." 确定性内核不会解释 missionstatement 文本——代理内部使用该文本作为推理指南，而 Runtime 通过比对提议中的 missioncontexthash 与注册在 Agent Registry 中的不可变值来强制任务完整性。如果提示词注入或运行时漂移改变了代理的目标，哈希将不再匹配，提议会被拒绝——无需进行语义解释。哈希只是实现方式的一种，关键是边界处必须有确定性完整性保证。
Mission 在部署时定义，只有通过合同版本控制的更新流程才能演进——不允许通过提示词调整、用户反馈或运行时协商来随意修改。在实践中，这意味着优化策略处于变更控制之下。一个任务随每次对话漂移的代理，不是持久的生产参与者，只是一个会话。
工程支柱三：认知隔离——声明而非命令（Explain 与 Policy 的区别）
代理的核心认知产物有两类：Explain（解释）和 PolicyProposal（政策建议）。Explain 描述现状、说明理由；PolicyProposal 是结构化的、带类型的声明，明确表示代理希望系统执行的操作。代理可以调用工具收集只读上下文，但所有状态变更的权威都在下游的确定性验证和执行门控。 代理的唯一状态变更可归因步骤是 emitpolicyproposal——这是一种结构化的、类型化的声明，不是直接执行。在上述承保场景中：代理读取文档后生成 Explain 叙述，然后发出报价的 PolicyProposal。但由于房产价值 1500 万英镑、合同授权上限 1000 万英镑，提议进入内核后被 Runtime 确定性拒绝，执行被转换为 ESCALATED 状态——这正是在一个决策中"人在环"的体现。
认知隔离：结构化输出作为安全边界
Contract 定义边界，Mission 定义目标，而 Epistemic Isolation 定义了唯一可接受的输出形式。
ROA Agent 与外部世界的交互，必须且只能通过结构化、类型化的 PolicyProposal 工件完成。Agent 的输出本质上是"不受信任的声明"——它提出一个行动建议，等待系统判断是否执行。Runtime 将其精确地视为待裁决的提案，而非直接执行的指令。
这正是 ROA + Runtime 模式能有效抵御提示词注入的关键所在。即使攻击者绕过了 LLM 的推理护栏，被篡改的输出仍以类型化提案的形式抵达执行层——提案中附带了 agentid。如果提案要求转账，但该 Agent 的 Contract 并未授予此权限，Runtime 会直接以 RBACDENIED 拒绝。安全来自执行边界处的确定性校验，而非对 LLM 对齐能力的信任。
从概率推理到确定性声明的桥梁
为了在概率性思维与确定性声明之间建立清晰桥梁，ROA Agent 通过严格的内部工作流完成决策，在 Explain 与 Policy 之间保持清晰分离：
- Explain：Agent 解析上下文，用自然语言描述 situation（例如："洪水风险评分 3/10……"）。这为人工审计创建了叙事产物，绝不会被解析为执行逻辑。
- Policy：Agent 构造结构化的 PolicyProposal，其中包含 Runtime 可确定性校验的执行字段。以保险承保为例：
评论