Dispatches from O'Reilly: From capabilities to responsibilities​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​​​​​‌‍​‍​‍‌​‍‌​‌‌‌‍‌‍​‌​‍‌​‌‌‍​‌‍​‍​‍‌​‍‌​‌​‌‍‌​‌‍‌​​‍​​‍‌‌

O'Reilly动态：从能力到责任 - Stack Overflow

2026年6月19日

O'Reilly动态：从能力到责任

为高风险执行设计受约束的AI代理。

[

[编辑注：本文最初发表在O’Reilly Media的博客Radar上。]

人机协作成为操作瓶颈

在我之前的文章《Agentic AI中缺失的一层》中，我主张AI代理需要一个确定性的执行内核——一个特权的“内核空间”，在代理影响现实世界之前验证每一个拟议的操作。那篇文章的重点是执行边界处发生的事情：幂等性、即时状态验证和与DFID相关的遥测数据。但建立这个边界立即引发了一个自然的问题：究竟谁在跨越这个边界，又是基于什么权限？

本文关注的是一个更狭窄且要求更高的系统类别。我们讨论的不是RAG聊天机器人、研究协作者或仅用于检索和总结信息的轻量级助手。我们的目标是高风险的代理系统：这些系统被允许通过移动资金、更改基础设施或修改关键记录来改变外部状态。这里提出的方法不是一个通用的代理框架；它是一个用于具有副作用系统的执行模式。

高风险的AI系统必须围绕责任进行设计，而不是能力。

目前行业给出的答案令人不满意：人机协作（Human-in-the-Loop，HITL）。在开发环境和低频率的流程中，将不确定的决策路由给人类是可辩护的。但在大规模的生产系统中——数十个代理，每小时数百个决策——这变成了可扩展性陷阱。

图1：人机协作（HITL）模型退化为操作瓶颈，用警报疲劳和未经验证的执行取代了真正的治理。

在操作上，失败是显而易见的。一个代理标记一个决策以供审查。一个人类批准了它。然后另一个到来，接着是数十个。队列增长。人类开始点击通过。他们不再阅读JSON负载。他们点击“批准”，因为积压的事务越来越多，会议将在十分钟内开始，而且到目前为止还没有发生灾难性的错误。这就是警报疲劳：治理退化为手动吞吐量管理。问题不是人类的弱点；而是由于将太多二进制决策路由到手动队列而产生的治理层技术债务。

Tyler Akidau在《Posthuman: We All Built Agents. Nobody Built HR.》中捕捉到了更广泛的问题，呼应了Tim O’Reilly对AI时代缺失协议的呼吁：行业在代理能力上投入了大量资源，但在治理权威、约束和问责的基础设施上投入却少得多。

可扩展的AI并不意味着雇佣更多的审核人员来监督更多的机器人。这意味着完全改变治理模型。可扩展的替代方案是异常治理（Governance by Exception）：人类设计政策，运行时执行它，只有真正异常的情况才会被升级。

在组织设计中，角色是稳定且被分配的。就像传统软件中的基于角色的访问控制（RBAC）一样，它定义了某人被授权可以做什么，与他们恰好执行的任务无关。我们无法规定一个人如何思考，但我们可以严格界定他们被允许做的事情。责任声明使这一界限变得明确。在软件中，我们似乎忘记了这一区别，希望依靠原始的智能——更好的模型、更紧密的提示、更完善的对齐——就能作为足够的护栏。

在一些企业领域中，这种区别变得更加清晰：

• 金融：能力是“可以执行股票交易”。责任是“被授权执行单笔订单最多5万美元，仅限于流动性高的股票，且每日最大亏损不得超过2%”。

• 医疗运营：能力是“可以重新安排患者预约”。责任是“被授权在14天窗口期内重新安排非关键的门诊访问，严格避免专科医生的重复预约”。

• 供应链：能力是“可以重新安排货运”。责任是“被授权将非危险货物重新路由，但最大SLA处罚预算不得超过5000美元”。

在涉及资金、医疗记录或物理物流的系统中，这两个声明之间的差距就是演示与生产部署之间的差距。

当前的范式通常通过提示来处理这种差距。给LLM一个API密钥，告诉它“要小心仓位管理”，并希望在对抗性输入、不寻常的市场条件以及边缘案例的诱惑逻辑下，对齐性依然保持。在低风险的环境中，这可能是可以接受的。但在具有现实世界副作用的高风险系统中，这并不是一个足够的控制表面。

这种区别并不是新的。几十年前，分布式系统就解决了类似的问题。

Carl Hewitt在1973年提出的Actor模型为我们提供了一个有用的基石。Actor是一个独立的计算实体，拥有自己的状态、自己的行为和自己的消息接口。Actor不共享状态，它们仅通过传递消息进行通信。关键的是，Actor的行为是有限的——由它接受哪些消息来定义，而不是由一个开放的能力集来定义。

责任导向代理（ROA）并没有发明新的分布式系统原语。相反，它围绕一个不可预测的LLM核心，组合了已被验证的模式——有限的Actor、RBAC风格的权限封装、审计追踪和执行边界验证。实际上，ROA更接近于一个决策Actor，而不是一个完整的计算Actor：它维护自己的内部状态，但不直接改变外部世界。在一个稳定的角色、固定的任务和机器可执行的合同内，它接收业务事件，基于相关上下文进行推理，并向运行时发出一个PolicyProposal以进行验证。

它的职责是认知性的，而非执行性的。它解释当前的情况并构建意图。但与传统的Actor不同，ROA代理通过严格的职责分离来定义。在它的参考形式中，凭证位于代理的范围之外。它不会直接向外部系统打开执行通道，也不会自行写入状态。ROA代理可以使用工具来获取上下文（例如在沙箱中执行只读操作，如查询知识库），但对状态变更操作的授权必须经过确定性验证和执行门的处理。唯一可归因于代理的状态变更步骤是emit_policy_proposal()——一个结构化、类型化的声明，表示它希望系统执行某个操作。ROA定义了意图的形式；运行时决定该意图是否可以转化为行动。

这种分离是该架构最重要的属性。五个工程支柱定义了其在实际中的含义——每个支柱都针对推理与执行边界的不同失败模式，并且它们共同将LLM从一个概率性工具转变为一个可治理、可问责的系统组件。

为了使这一点更具体，想象一个在伦敦商业市场上的承保代理接收到一份房产提交。它阅读文件并生成一个解释性叙述。然后，它发出一个PolicyProposal以获取报价。但房产价值为1500万英镑，而其合同将授权上限设定为1000万英镑。该提案到达Kernel，运行时对YAML合同进行确定性评估，拒绝执行，并将流程转移到ESCALATED。高级承保人不再需要审查每一个200万英镑的提交。他们只会在这种特定的1500万英镑的例外情况下被通知。这就是“人环路”在一次决策中的体现。

ROA的工程支柱

#### 支柱1：责任合同——授权通过代码编码

如果角色定义了代理可以处理的决策类别，责任合同则定义了该授权的硬性边界。代理的授权范围不是一个提示，而是一个版本化、机器可读的合同，该合同在Agent Registry中注册——这是Kernel中代理身份的单一真实来源。这里有一个关键属性：提示是建议，代码是强制执行。一个提示“不要超过每笔交易10,000美元”可能被足够有动机的模型创造性地重新解释，或被精心设计的提示注入所覆盖。一个字段max_order_size_usd: 10000.0通过确定性运行时代码进行验证的合同，比自然语言指令更难以绕过。在参考架构中，合同是离线部署的——代理不会自行注册，也不会读取或修改自己的合同。

这种设计还有一个容易被忽视的二阶后果：角色定义自动限制了代理所需的数据上下文。如果一个承保代理在LOW和MEDIUM风险等级中被合同限制为仅处理HOME_STD和HOME_PLUS类型的保单，那么在每次推理调用之前，Context Compiler（负责组装代理的工作快照）只需提供与这些维度相关的信号。商业房产的市场数据、被排除风险等级的洪水区统计数据，以及其他产品线的监管数据则完全不在范围内。上下文通过合同被确定性地缩小。

这一点对具体的大型语言模型（LLM）工程原因至关重要。在实践中，随着模型工作上下文的扩展，模型的可靠性往往会降低，包括从业者所描述的一类效应，称为“迷失在中间”。一个范围明确的角色不仅仅是一种治理上的便利，它是一种架构机制，用于保持代理的工作上下文足够小，从而能够可靠地进行推理。与之相比，一个被赋予了所有可能相关上下文的通用代理更有可能退化，而一个在定义领域内运行的合同限定代理则更稳定。

在保险承保的示例中，该责任合同可以这样配置：

agents:
  - agent_id: "underwriter_agent"
    version: "1.0.0"
    created_by: "compliance@example.com"
    created_at: "2025-02-17T10:00:00Z"
    mission: |
      你是一名保险承保人。分析客户申请并提出一个保险方案。保费基于总保额价值（TiV）的约2%，上限为max_tiv。
      永远不要为烟花或加密货币挖矿行业提出方案——这些行业是被禁止的。
    contract:
      role: EXECUTOR
      max_tiv: 3000000
      prohibited_industries: ["Fireworks", "CryptoMining"]
      escalate_on_uncertainty: 0.65

#### 支柱 2：使命——北极星

使命在运行时是不可变的。如果责任合同定义了代理可以执行的操作，使命则定义了在这些边界内它试图优化的内容。这一区别在操作上非常重要：合同定义了允许的动作空间，而使命则定义了该空间内的排序逻辑。合同回答可能；使命回答应该。只要两个代理都保持在相同的硬性边界内，即使它们共享相同的权限范围，也可以优化不同的业务结果。

在ROA架构中，使命是一个部署工件，具有两个表面：一个用于代理作为推理指南的人类可读使命声明（mission_statement），以及一个用于运行时确保完整性的机器可验证使命上下文哈希（mission_context_hash）。

mission_statement: "在物流重新路由中最小化SLA处罚。优先选择低成本承运商。"
mission_context_hash: "sha256:a3f9b2c1..."   # 在部署时由内核计算，严格不可变

确定性的内核不会解释使命声明的文本。代理在内部使用该文本作为推理指南，而运行时通过将提案中的使命上下文哈希与代理注册表中注册的不可变值进行比较，来确保使命的完整性。如果提示注入或运行时漂移改变了代理的目标，哈希将不再匹配，提案将被拒绝，而无需进行语义解释。哈希只是一个实现方式；要求是在边界处实现确定性完整性。

使命在部署时定义，并且只能通过合同的有意、版本控制的更新来演变，而不是通过提示调整、用户反馈或运行时协商。实际上，使命将优化策略置于变更控制之下。一个使命随着每次对话而漂移的代理不是一个持久的生产参与者；它只是一次会话。

如果 Contract 定义了边界，Mission 定义了目标，那么 Epistemic Isolation 就定义了唯一可接受的输出形式。ROA 代理只能通过结构化、类型化的 PolicyProposal 工件与世界进行交互。代理的输出是一个不可信的声明——即它希望系统执行某项操作的断言——而 Runtime 会严格按照这种方式进行处理。

这一特性使 ROA + Runtime 模式在抵御提示注入方面具有显著优势。即使注入绕过了 LLM 的推理防护机制，被污染的输出仍然会以携带 agent_id 的类型化提案形式到达。如果提案要求转账，但代理的合同中没有该权限，Runtime 会以 RBAC_DENIED 拒绝该提案。安全性来源于执行边界处的确定性执行，而不是依赖于对齐 LLM 的信任。

为了清晰地将概率性思维转化为确定性声明，ROA 代理通过结构化的内部工作流程生成决策，并在 Explain 和 Policy 之间保持严格的分离：

• Explain：代理解释上下文，并用自然语言描述情况（例如，“洪水风险评分 3/10...”）。这会为人工审计员创建一个叙述性工件。它永远不会被解析用于执行逻辑。

• Policy：代理制定一个结构化的 PolicyProposal，其中包含 Runtime 可以确定性验证的执行相关字段。在承保示例中，它看起来像这样：

proposal = PolicyProposal(
  total_insured_value=2_750_000,
  premium=55_000,
  industry="Commercial Property",
  justification="TiV remains below delegated max_tiv and no prohibited industry indicators were found.",
  confidence=0.81,
)

绑定字段（total_insured_value、premium、industry）驱动确定性验证，而 justification 和 confidence 仍然是用于审计和升级的可观测性元数据。

这种分离使证据模型保持清晰：叙述保持可读性，策略保持可由机器执行，两者都可以绑定到相同的决策血统，而不会让自由文本渗入执行。

#### 第四支柱：Epistemic 长期性——跨决策周期的记忆

一旦代理拥有稳定的角色、固定的使命和严谨的输出接口，跨决策周期的连续性就变得有意义了。这是在实际实现中最常缺失的支柱——也是导致特定一类生产失败的主要原因：无限拒绝循环。

ROA 代理不是无状态的推理调用。它们是长期存在的实体，能够在多个周期中维护决策轨迹——由 Kernel 管理的先前提案记录、其验证结果以及这些决策的业务后果。

约束权限的相同作用域逻辑也决定了记忆是否具有意义。在稳定角色下长期运行的代理会从相同类型的决策中积累历史，这些决策在相似的约束下进行，过去的行动及其结果确实存在因果关系。一个被分配不相关任务的通用助手可能仍然会注意到模式，但这些相关性很少在操作上可靠。专注于责任是代理记忆中区分信号与巧合的关键。

这种失败模式有一个名称：决策遗忘。没有长期性，代理会重复相同的被拒绝意图，因为拒绝并未成为下一个决策周期的一部分。

#### 第五支柱：决策遥测——不可变的责任

每个 PolicyProposal 都携带一个决策流 ID（dfid），它将该提案与完整的决策上下文绑定。与其记录非结构化的日志，不如构建一个重建原语——一种关系追踪，连接以下内容：

• 输入：代理推理所依据的精确上下文快照（T0）。
• 验证：与责任合同评估的验证结果。
• 结果：最终的执行收据。

这种相关记录使得可以通过标准 SQL 联接在整个决策生命周期中回答“为什么这个代理在特定时刻做出这个决定，基于世界的什么状态？”在高保障部署中，相同的结构化遥测可以封装成一个经过密码学签名的证明携带意图，允许独立验证决策工件，而无需任何人信任可变的文本日志——这正是欧盟人工智能法案等高风险合规制度所推动的方向。

但结构化决策遥测的作用不仅限于支持日常的事故回顾。每个决策都成为一个由 DFID 绑定的结构化关系记录——这与使诸如代理漂移等宏观失败在它们在舰队中静默累积之前被检测到的基础相同。

人环内循环——规模化自主性

“人环内循环”（Human-in-the-Loop）的替代方案不是移除人类，而是将人类从执行循环移动到设计循环。

这就是“人环外循环”（Human-Over-The-Loop，HOTL）模型。人类作为策略设计者，定义并演进治理决策的合同，而系统则在这些边界内自主运行。没有审批队列，没有审查疲劳。基于例外的治理是可扩展的模型。

图 2：人环外循环将人类从执行队列转移到设计循环。代理在确定性合同内自主运行；人类通过定义该合同并仅在真实例外情况下进行干预来治理。

升级触发条件。系统仅在代理遇到其合同未授权其单独解决的情况时才会升级：

• 提议的操作超过合同授权限制
• 代理的置信度低于 escalate_on_uncertainty 阈值
• 外部 API 错误超过重试预算
• 在配置的不活动窗口内未发出任何决策

当触发条件发生时，DecisionFlow 进入 ESCALATED 状态。操作员可以看到 WorkingContext、PolicyProposal 和升级原因，并可以 OVERRIDE、MODIFY 或 ABORT。这不是一个“批准/拒绝”队列，而是有针对性的干预。

升级不应被理解为代理可靠地知道其不知道的证明。大型语言模型（LLMs）对自己不确定性的判断很差，因此架构不信任内省。escalate_on_uncertainty 阈值是一个有用的启发式方法，而不是事实：当声明的置信度低于阈值，或提议违反内核可以确定性评估的合同参数时，系统会强制升级。如果模型以高置信度生成了一个糟糕的提议，运行时仍然会阻止它。代理可能会发出不确定性信号；运行时决定该不确定性是否重要。

冻结上下文 + JIT（即时编译）。操作员根据代理在 T0 时刻所看到的世界的精确快照来审查提议，从而避免了 TOCTOU（检查时间到使用时间）问题：人类使用机器在当时看到的相同数据来审核机器的决策。

但世界在不断变化。在 T1 时刻点击“OVERRIDE”并不会盲目执行该动作；它会强制提议通过运行时的 JIT（即时）验证关卡。如果在 T0 和 T1 之间，现实已经偏离了合同的漂移范围，运行时会拒绝覆盖操作，而不是执行一个针对过时状态的曾经有效的意图。

合同演进。对于一个合法的边缘情况，正确的长期应对措施通常是修改合同，而不是重复覆盖。如果业务现实发生变化，操作员会更新责任合同并部署新版本。系统通过版本控制的治理边界进行适应，而不是通过即时编辑或微调。

升级预算。升级操作对每个代理都有令牌桶限制（例如，每小时 3 次升级）。如果某个代理用尽了该预算，运行时会将其状态转换为“SUSPENDED”，记录状态变化，并阻止新的决策流程，直到操作员介入。这可以防止升级型 DDoS 攻击，并控制失控的推理成本。

自信 ≠ 权限。代理可以以 confidence=0.99 的置信度发出一个提议，但如果该提议超过了合同的权限，运行时会拒绝它。自我评估的确定性并不等于权限。

图 3：HITL 随着代理数量的增加而扩展监督成本。HOTL 将这种成本转移到策略设计上——人类管理生产线，而不是单个决策。

包裹而非替代：现有框架的作用

采用 ROA 模式并不意味着放弃工程团队过去一年所掌握的工具。像 LangChain、AutoGen 和 CrewAI 这样的框架在协调复杂的推理循环、RAG 管道和工具使用方面表现出色。ROA 并不是为了与它们竞争而设计的；它的设计目的是治理它们。

图 4：ROA 模式将现有的编排框架（如 LangChain 或 CrewAI）包裹在用户空间中，限制直接执行，并强制输出通过由内核空间验证的结构化策略提议。

在实践中，你可以将一个成熟的 LangChain 代理封装在 ROA 的边界内。底层框架仍然处理概率推理（用户空间的编排）。架构的转变简单但影响深远：你过滤了框架的工具空间。你物理地从 LangChain 代理的工具箱中移除了 exchange.execute_trade() 或 db.drop_table()。取而代之的是，你为其提供了一个单一的、沙箱化的工具：emit_policy_proposal()。代理进行推理、迭代，最终调用该工具发出最终意图。ROA 包装器捕获这个请求，可能执行一个本地的自我检查作为降噪启发式方法，并将策略提议传递到内核空间进行实际执行。你保留了框架的强大功能，但在关键位置获得了确定性执行治理。

成本与权衡

ROA 并非免费。它引入了工程开销，正是因为它用明确的治理取代了非正式的信任。

• 验证关卡和 JIT 检查会增加每个具有副作用的决策的延迟。

• 责任合同增加了设计开销：作者身份、版本控制、所有权和审查现在必须明确。

• 与 DFID 相关联的可审计性增加了存储、追踪和操作集成的工作量。

• 升级阈值和预算需要领域调优；不好的默认值要么会淹没操作人员，要么会隐藏合法的例外情况。

这些成本只有在错误副作用的负面影响明显高于控制其成本时才是合理的。对于 RAG 聊天机器人和低风险助手来说，这种架构通常是过度的。对于高风险系统而言，这是构建真正边界的成本。

结论：架构，而非炼金术

五大支柱。一个架构承诺：一个无法被信任自我管理的代理，必须在一个能够管理它的系统中运行。责任合同界定权威。任务锁定目标。认识隔离确保输出是一个声明，而不是一个命令。持久性防止系统忘记它已经学到的内容。审计使每个决策都可以被重建。ROA 模式——用责任合同代替能力列表，用声明代替命令，用确定性内核代替非正式提示——将这些组合成一个可执行的边界。意图由代理结构化。边界由合同强制执行。遥测数据由 DFID 收集。人环路模型将人类判断保留给真正的例外情况，而不是批准队列。它们一起将一个概率模型转化为一个可管理的生产行为体。

一旦确定性执行边界和与 DFID 相关联的遥测数据就位，就有可能提出一类新的第三天问题：哪些代理在限制范围内却悄悄地破坏了利润？哪些决策模式在人类察觉到偏移之前就值得自动暂停？我们如何根据监管标准重建任何行动，管理一个代理具有不同风险配置和决策权重的舰队？

责任是缺失的执行治理层——它应属于架构，而不是系统提示。

AI 演示的时代正在结束。AI 生产系统的时代正在开始。这些系统不仅将因其模型的智能而与众不同，还将因其治理的严谨性而与众不同。

本文对责任导向代理和决策智能运行时及其在生产弹性和运营挑战方面的方法进行了高层次的介绍。完整的 DIR 规范、ROA 合同模式、参考实现作为开源项目可在 GitHub 上获取。