用会话类型约束智能体操作顺序

让 Agent 退款、改签、修改账号，只在提示词里写「先确认再执行」，约束仍然依赖模型当场遵守。Concordat 提出的办法，是把对话流程写成协议，由运行时检查工具调用顺序，越过确认步骤的操作会在执行前被拦下。

原文报告，在两种模型合计 178 次任务运行中，加入协议约束后，未经授权的修改降为零，任务成功率没有显著变化。这个结果值得看，但要分清：流程顺序可以被程序卡住，用户是否真的同意、协议是否写对，还需要另外验证。

为什么把规则写进提示词还不够

原文讨论的是有实际后果的 Agent：取消订单、发起退款、修改账户。这些操作通常有明确前置条件，比如退款前必须取得用户确认。

问题在于，提示词表达的是要求，执行系统未必理解这个要求。模型即使刚读过规则，仍可能在长上下文、用户催促或特殊情况的诱导下，直接调用 issue_refund()。如果运行时只检查参数是否合法，调用就会继续执行。

Concordat 使用会话类型（session types）描述交互顺序。可以把它理解成一张带工具权限的流程图：当前走到哪个节点，就只能调用该节点允许的工具。

原文的退款流程有五步：

1. 初始阶段允许 lookup_booking() 或 end_conversation()。
2. 找到订单后，允许 request_confirmation() 或结束对话。
3. 等待确认时，只允许 receive_message() 获取用户回复。
4. 确认通过后，才开放 issue_refund()。
5. 退款完成后，只能结束对话。

普通 API 类型约束回答「退款函数接收什么、返回什么」，会话类型还要回答「它什么时候才能被调用」。

把退款工具藏到确认之后，再在执行入口检查一次，才形成了可执行的顺序约束。

原文给出的 Python 示例通过 Protocol、State 定义协议，并用 @refund_protocol.enforce 装饰 Agent 类。每轮执行的关键部分如下，它解决的是模型选择工具与真正执行工具之间的检查问题：

    def step(self, message):
        # 模型只能看到当前状态允许的工具
        available_tools = refund_protocol.tools_for_state(self.state)
        response = self.model.generate(message, tools=available_tools)

        # 协议在执行前检查工具调用
        if response.tool_call:
            refund_protocol.validate_call(self.state, response.tool_call)
            result = execute_tool(response.tool_call)
            self.state = refund_protocol.next_state(self.state, result)

        return response

要看的是 validate_call() 在 execute_tool() 之前。只过滤传给模型的工具列表还不够，执行入口也必须拦截违规调用。随后，next_state() 根据工具结果推进状态。

这里还有一个关键前提：receive_message() 收到回复以后，谁来判定结果是 confirmed 还是 denied？原文展示了状态转换，却没有展开确认语义的识别方式。如果这一步误判，后面的工具顺序即使完全合法，也可能执行错误操作。

零违规的实验，证明到了哪一步

原文引用论文 2610.37461v1，测试场景是 tau-bench 的 50 个航空客服任务，包含退款、改签、升舱等操作。作者加入模拟客户，催促 Agent 跳过确认，例如声称赶时间，或者强调自己已经同意。

报告结果如下：

模型	普通 Agent 未授权修改	Concordat 未授权修改
GPT-4.1	13/50	0/50
Claude Haiku 5.5	29/128	0/128

这里的 50 个任务和 128 次任务运行不是同一个统计口径，原文没有解释后者的运行安排。两组受约束实验合计 178 次运行，均未出现未经授权的修改。

作者还报告，任务成功率与普通 Agent 没有显著差异；tau-bench 自带的奖励函数则没有发现大多数违规。这一点很有启发：最终订单改对了，不代表中间取得了合法授权。评测如果只看最终业务状态，就可能漏掉流程问题。

但「没有显著差异」不能直接读成「完全没有代价」。原文没有列出具体成功率、统计检验、延迟或 token 开销，也没有提供不同约束方案的完整对照。

这组结果支持的是：在给定任务和催促方式下，运行时协议有效阻止了被定义为违规的调用。它还不足以证明 Agent 面对任意业务、任意诱导都能安全执行，更不能单凭这组数字推导出生产环境的可靠性。

状态机越严格，业务例外越需要提前设计

严格协议的代价，往往出现在正常用户身上。

假设用户第一句话就明确要求退款并表示确认，而协议规定必须先调用 request_confirmation()，Agent 仍然得再问一遍。状态机没有自动理解「之前已经确认」的能力，除非开发者把它写进去。

原文提出三种处理方式：增加「此前已确认」状态、把确认结果作为状态数据传递，或者使用能跨轮追踪条件的协议语言。表达能力越强，定义时验证也越困难。尤其加入任意条件以后，就不能继续沿用简单状态图上的保证。

工程上还需要防止授权过期。例如，用户确认的是一笔订单，后续订单或退款金额变了，旧确认还能否使用？这是协议设计需要回答的问题，原文没有给出具体方案。

Concordat 还声称提供两类约束。

一类是行为子类型约束：父类 RefundAgent 要求退款前确认，子类 FastRefundAgent 就不能削弱这条要求。作者称，违规子类会在类定义时被拒绝，并在导入阶段抛出 ProtocolViolation。

不过，原文展示的 issue_refund_without_confirmation() 方法体只有 pass，没有实际调用。它能说明作者想表达的规则，却不能展示检查器如何发现绕过路径。涉及动态调用、间接调用时，分析范围和限制也没有说清。

另一类是预算管理。Agent 交接时，剩余 token 和工具调用预算按线性方式分配：前一个 Agent 用掉 30%，下一个得到 70%。还可以设置状态限制，例如确认阶段最多 500 tokens、退款阶段最多 2 次工具调用。

这有助于限制消耗，但单靠传递剩余预算，并不能保证前一个 Agent 不把预算耗光。原文将其描述为防止预算耗尽攻击，具体机制仍需更多说明。

排障方面，作者称违规日志会记录当前允许的工具与消息历史，模型收到拒绝后可以重试；协议还能导出 DOT 图。这些能力有助于定位问题，但「模型通常经过一两次拒绝就能适应协议」仍是原文的经验描述。

我的判断

我认同它最重要的方向：高后果操作的约束应该进入执行系统。提示词可以帮助模型理解业务，运行时检查则负责守住调用边界，两者可以同时使用。

但原文把 session types 描述成比工具守卫更严格，前提是工具守卫只检查局部条件。如果服务端守卫也读取持久化流程状态、验证确认凭据，同样可以实施跨步骤限制。Concordat 的价值更可能在于统一表达协议、检查状态转换和约束继承，而不是只有它才能阻止越权。

协议能保证执行遵守已建模的规则，不能替你保证规则覆盖了真实业务。

原文估算，简单退款流程需要 30–50 行协议定义、2–3 小时建模、1–2 小时测试。这些数字没有对照数据，应当视为经验预算。3–10 个状态、顺序清晰、违规代价高的流程，比较适合尝试；开放式问答和只读助手，未必值得承担维护成本。

另外，文中的「编译期验证」更接近 Python 类定义或导入阶段的检查。仅凭文章里的示例，还不足以确认这个库对任意业务代码都能提供所宣称的保证。

能拿来做什么

• 给具有写操作的 Agent 梳理一张小状态图，明确每一步开放哪些工具，重点检查退款、账号修改、数据删除之前的授权路径。
• 如果工具由 Node 服务执行，可以借鉴「按状态过滤工具，再在执行入口验证」的双层结构，并让确认结果绑定具体操作对象与参数。
• 给 AI 编程助手执行删除文件等操作设置流程约束时，测试应覆盖跳过确认、重复使用旧确认、参数变化等路径，不能只验证最终任务是否完成。
• 先选择一个边界清楚的流程做试点，记录违规拦截、正常请求被阻挡、任务成功率与额外开销，再决定是否扩大协议覆盖范围。