title: “企业级 AI Agent 智能体系统：人机协同流程”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “企业级 AI Agent；人机协同；人类监督；审批门控；可逆性；AgentOps；审计”

企业级 AI Agent 智能体系统：人机协同流程

标题解释假设：本文将标题理解为“面向企业生产部署的 LLM Agent 系统，如何设计可执行、可审计、可随风险调节的人机协同流程”。论文不绑定某一特定模型、厂商或多智能体框架，而把 Agent 视为能够调用工具、读写企业系统并产生外部副作用的软件实体；讨论重点是任务委托、风险分级、审批门控、执行监督、审计回放与反馈学习六个环节。若读者关注的是纯 Agent 能力提升或多智能体对话编排，本文将后者视为可替换的执行底座，而非核心贡献。

Abstract

企业正把基于大语言模型（Large Language Model, LLM）的智能体（Agent）从演示环境推进到生产流程。智能体能够浏览网页、执行代码、调用企业系统并产生真实副作用，这使任务委托的收益与风险同时放大。现有研究多从模型能力、基准评测或运行时可观测性切入，人的角色常被简化为事后的审批弹窗；完全自主与逐动作审批因此在企业场景中都不易规模化。本文提出企业人机协同框架（Enterprise Human-Agent Collaboration Framework, HACF），把任务契约、风险感知路由、同意完整性门控、协作账本与受约束反馈学习组织为可执行的运行时流程。HACF 依据动作的利害程度、外部可见性、可逆性与不确定性，在自主执行、监督执行、协同执行与升级接管四种模式间路由，并将人工批准绑定到规范化后的真实动作，而非智能体的自述。本文给出该流程的形式化目标、安全与审计性质，以及覆盖任务成功、严重伤害、未经授权不可逆动作、人工负担、审批精度与审计完整性的可复现评估协议。截至写作时，本文尚未完成真实企业部署实验，定量结果均以占位符标注；本文的贡献是流程抽象、可检验的设计假设与实验方案，而非已证实的性能结论。HACF 将人机协同从界面问题提升为可治理的系统对象，为企业智能体的渐进式授权提供设计基线。

关键词：企业级 AI Agent；人机协同；人类监督；审批门控；可逆性；AgentOps；审计

---

你离拥有一支永不停歇、持续进化的 AI 超级研发团队，只差一次 git clone——DeepThink 是 AI Genius Institute & 光剑AI 打造的开源、免费、可自由使用的私有 AI 操作系统（AI OS）：在安全隔离的沙箱中自主执行代码、管理文件、完成超复杂长程任务，作为自托管、多用户、本地优先的 AI Agent Loop Engineering 系统，支持桌面端+浏览器+移动端，让 DeepThink 成为你的全能数字助手；它不止让你使用 AI，更要让你从工具使用者进化为代码创造者，最终成长为可自我繁衍的超级智能体，让每家企业都拥有自己的 AI 超级研发团队，一起走向 AGI——现在就去 git clone，顺手点亮 Star：你收藏的不是一个仓库，而是通往 AGI 的入场券。🚀

DeepThink，开源企业级自主 Agent 超级智能体自进化平台，是从 Harness Engineering 到 Loop Engineering 范式的先行者，面向企业客户的新一代 AI 基础设施（AI Infra）。DeepThink 平台以多 Agent 协作框架为核心，融合 AI 自主编程（AI Coding）、自主进化（Self-Evolving）、全栈可观测性（Full-Stack Observability）、Bug 自修复闭环（Bug Auto-Fix Loop） 与 程序员-Agent 共生协作（Human-Agent Symbiosis），构建一个能持续学习、自我改进、最终成长为超级智能体的企业级 AI 系统。

DeepThink 项目开源代码（如果你觉得好玩，就一起来玩， Star 一下）：
Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink
Github: https://github.com/AIGeniusInstitute/deepthink

---

1 Introduction

1.1 从“回答问题”到“代为行动”

企业软件的使用方式正在发生变化。过去，员工在多个系统之间手工搬运信息、填写表单、执行审批；现在，基于 LLM 的 Agent 可以读取工单、浏览内部网页、调用业务接口、修改文件、发送邮件，并在一个较长的时间跨度内连续执行多步操作。ReAct 把推理与行动交错组织 [1]，Reflexion 通过语言反馈改进行为 [2]，AutoGen 与 MetaGPT 把多智能体协作引入应用构建 [3,4]，Voyager 展示了开放式技能积累的可能 [5]，OpenHands 则把软件开发的工具链封装为通用 Agent 平台 [6]。这些工作共同说明：Agent 的能力边界正在从“生成文本”扩展到“改变外部状态”。

能力扩展也改变了风险结构。聊天模型的错误主要表现为错误信息，企业 Agent 的错误可能表现为错误付款、错误删除、越权访问、对外发送不当内容，或者在长程任务中逐步偏离原始目标。任务越接近真实业务，动作的外部可见性和不可逆性越高，单次错误的代价也越难用“重新生成”来抵消。因此，企业采用 Agent 的关键问题不只是“模型够不够强”，而是“在什么条件下、由谁、以什么粒度、基于什么证据，允许 Agent 执行哪一个动作”。

1.2 两种直觉及其局限

围绕人类监督，产业界形成了两种直觉。第一种是“尽可能自主”：给 Agent 完整的工具权限，让它端到端完成任务，人类只在最后验收。第二种是“尽可能审批”：每一个工具调用都弹出确认框，人类逐项点击允许或拒绝。两种直觉都抓住了部分事实，但在企业规模下都不够。

完全自主的局限在于尾部风险。生产系统对可靠性的要求通常高于演示系统；一旦出现提示注入、工具投毒、上下文污染或长程规划漂移，Agent 可能在无人察觉的情况下执行高代价动作。TheAgentCompany 在模拟软件公司环境中评测数字工作者型 Agent，发现最具竞争力的基线也只能自主完成约 30% 的任务 [11]；这说明真实工作任务的长程性、跨系统性和规则约束仍然构成显著障碍。Measuring Agents in Production 对 20 个案例和 86 名从业者的研究进一步显示，68% 的生产系统在人工介入前最多执行 10 步 [13]。换言之，当前企业实践并非“完全自主”，而是“短程自主 + 频繁人工介入”的混合形态。

逐动作审批的局限在于人的注意力是稀缺资源。审批弹窗把安全责任转移给人类，却没有同时提供足够的上下文、证据和可比较的选项。审批次数一多，人就会形成“看到就点允许”的习惯；审批文本若由 Agent 自己撰写，人批准的甚至可能不是实际执行的动作。针对软件从业者的混合方法研究发现，实践者主要依据可直接观察和复核的信息理解 Agent 行为，而决策、数据使用和后台活动往往不透明；审批严格程度会随信任、任务重要性、时间压力和后果而变化 [20]。针对用户级权限的研究指出，现有方案在可用性、透明度和用户控制方面仍存在明显缺口 [22]。针对普通用户的对照实验则发现，预先编写的“允许/询问/禁止”规则并不必然比逐动作人工批准提供更强保护，因为大量越界动作仍在人工批准后被执行 [23]。这些结果共同说明：把“人在回路”简化为“多弹窗”并不能自动带来安全。

更微妙的问题在于“批准的是什么”。如果审批界面展示的是 Agent 对动作的自然语言摘要，而实际执行的是另一个底层调用，那么人类批准的是叙事，不是动作。What You Approve Is What Executes 把这一缺失性质称为“同意完整性”（Consent Integrity），并展示了黑盒 Agent 的审批摘要可被伪造的风险 [26]。因此，企业协同流程必须回答四个问题：人类在批准哪一个具体动作；该动作的后果是否被忠实呈现；批准的范围和有效期是什么；执行结果能否被独立审计。

1.3 本文思路：把协同流程作为一等对象

本文的核心判断是：企业 Agent 的安全性不能只靠模型对齐或事后监控，而需要把“人机协同”本身设计为可执行、可验证、可迭代的运行时对象。协同不是 Agent 之外的一层界面，而是与规划、工具调用、状态更新同等重要的系统组件。基于这一判断，本文提出 HACF（Enterprise Human-Agent Collaboration Framework，企业人机协同框架）。

HACF 包含五个相互衔接的模块。第一，任务契约编译器把自然语言请求转换为结构化契约，明确目标、允许动作、禁止动作、数据边界、风险预算、证据要求和成功标准，避免 Agent 在运行中静默扩权。第二，风险感知路由器根据动作的利害程度、外部可见性、可逆性和不确定性，在四种协同模式之间选择：自主执行、监督执行、协同执行和升级接管。第三，同意完整性门控从规范化后的真实动作独立渲染审批请求，把批准令牌绑定到动作哈希、批准人、范围和有效期，并在执行前再次校验。第四，协作账本以哈希链记录契约、计划、动作、证据、人工决策、执行结果和回滚事件，支持审计、回放与事件调查。第五，受约束反馈学习利用人工决策和事后结果调整风险阈值与路由策略，但设置不可逾越的安全约束，例如不得学习自动批准不可逆动作。

HACF 的设计遵循三条原则。其一是风险相称：监督强度应随动作风险变化，而不是对所有动作施加同等审批。其二是同意完整：人类批准的动作必须与实际执行的动作一致，批准范围必须明确且可撤销。其三是可审计默认：关键状态转换在默认情况下留下可验证记录，而不是在事故发生后临时拼接日志。三条原则共同把“人机协同”从经验性操作转化为可讨论、可测试、可治理的工程对象。

1.4 主要贡献

本文的贡献可以概括为四点。

• 提出 HACF 流程框架：把任务契约、风险路由、同意完整性门控、协作账本和受约束反馈学习统一为可执行的运行时流程，并给出模块接口、状态转换和异常处理规则。
• 给出面向企业副作用动作的风险表示与路由规则：显式建模利害程度、外部可见性、可逆性和不确定性，将可逆性分为幂等、可逆、可补偿和不可逆四类，并据此选择四种协同模式。
• 设计同意完整性门控与哈希链账本：使人工批准绑定到规范化动作而非 Agent 自述，支持范围化授权、双人复核、执行前校验、事后回放和篡改检测。
• 给出可复现的评估协议：覆盖任务成功、严重伤害、未经授权不可逆动作、人工介入负担、审批精度、审计完整性和回滚成功率，并明确区分设计假设与待测结论。本文不报告未经实测的数值。

本文余下部分安排如下。第 2 节按技术流派回顾相关研究，并说明本文与它们的差异。第 3 节给出问题形式化、框架总览、模块细节、工作流以及复杂度与性质。第 4 节给出实验设计、指标、基线和结果记录模板。第 5 节讨论适用边界、伦理影响和部署路径。第 6 节总结全文。附录给出契约与批准令牌的字段设计、门控算法、威胁模型、评估清单和标准映射。

2 Related Work

2.1 从推理到行动：LLM Agent 的能力路线

LLM Agent 的第一条研究路线关注如何把语言模型的推理能力转化为可执行的行为。ReAct 让模型交错生成推理轨迹和动作，使推理帮助规划、动作帮助获取外部信息 [1]。Reflexion 不更新模型权重，而是把任务反馈转化为语言反思并存入情景记忆，以改进后续尝试 [2]。这类工作奠定了“规划—行动—观察—再规划”的基本循环，但主要关注单智能体的任务表现，对“何时应把控制权交给人类”讨论较少。

第二条路线关注多智能体编排。AutoGen 把可对话的 Agent 作为基本组件，支持多 Agent 协作与工具调用 [3]；MetaGPT 通过元编程把人类标准作业流程编码为多 Agent 角色分工 [4]；Voyager 在开放式环境中积累可复用的技能库 [5]；OpenHands 提供面向软件开发的通用 Agent 平台与沙箱 [6]。这些系统提升了任务分解、并行化和工具复用能力，但其评价重点通常是任务完成度，而非协同过程的治理属性。HACF 不替代这些编排框架，而是在其外层增加契约、风险路由、审批绑定和审计闭环；换言之，AutoGen 或 OpenHands 可以作为 HACF 的执行底座，但不能单独提供企业所需的授权与问责机制。

2.2 企业工作场景中的 Agent 评测

第三条路线关注真实工作场景中的评测。WebArena 构建了可复现的网页环境，用于评测自主 Agent 的浏览与操作能力 [7]；OSWorld 把评测扩展到真实计算机环境中的开放式任务 [8]；SWE-bench 以真实 GitHub 议题评测代码修复能力 [9]；τ-bench 则把工具调用、用户交互和领域规则放在同一个基准中考察 [10]。TheAgentCompany 进一步模拟一个小型软件公司的内部系统、同事协作和跨角色任务，发现最强基线也只能自主完成约 30% 的任务 [11]。这些基准推动了 Agent 能力评估，但它们主要测量“任务是否完成”，较少测量“完成过程是否可授权、可解释、可审计”。

AI Agents That Matter 指出，当前 Agent 评测过度关注准确率，忽视成本、复杂度和可复现性，导致“最优”系统可能昂贵而脆弱 [12]。Agent-as-a-Judge 尝试用 Agent 评估 Agent 的中间步骤，以降低人工评估成本 [19]。HACF 的评估协议吸收了这一批评：除了任务成功率，还测量人工分钟数、提示次数、审批精度、审计完整性和回滚成功率。与上述工作相比，本文的评估对象不是单一 Agent 的能力，而是“人—Agent—工具—账本”组成的协同系统。

2.3 人在回路、权限设计与可逆性

第四条路线来自人机交互、安全与软件工程。Salerno 等人通过 18 名从业者的访谈和 115 名从业者的问卷，研究 Agent 权限决策，发现实践者依赖可观察、可复核的信息，审批严格程度受信任、任务重要性、时间压力和后果影响 [20]。Michael 和 Roesner 梳理了 21 个用户级 Agent 权限方案和 5 个商业 Agent，指出可用性、透明度和用户控制方面仍有显著缺口 [22]。Yan 通过 113 名参与者的对照实验比较逐动作人工批准、模型自动审查和用户预写策略，发现预写策略并未必然带来更强保护，许多越界动作仍在人工批准后执行 [23]。Pochampally 等人提出“委托后悔”（delegation regret）概念，发现用户会按任务而非按 Agent 校准信任，不可逆且外部可见的动作最容易引发信任撤回 [25]。

Zhai 等人从可逆性角度形式化 Agent 执行，把动作分为幂等、可逆、可补偿和不可逆四类，并指出 Agent 的灵活性受其可逆性边界约束 [24]。Weng 则从安全角度提出同意完整性，强调人类批准的内容必须由可信中介从真实动作渲染，并绑定到实际执行的动作，而不能信任 Agent 的自述 [26]。Wang 等人进一步主张，LLM Agent 安全本质上是“Agent—人类交互”问题，并指出现有生产系统主要依赖策略配置、运行时批准和范围配置，但这些机制在认知负担与安全保障之间存在根本权衡 [21]。

这些工作为 HACF 提供了直接经验：审批不是越多越好；权限需要按用户和任务定制；可逆性应成为核心风险维度；批准必须绑定真实动作。与它们相比，HACF 的差异在于把这些分散的洞察组织为一条完整的运行时流程，并给出契约、路由、门控、账本和反馈学习之间的接口。本文不把审批界面视为独立产品功能，而把它视为与 Agent 执行循环共享状态和证据的协议层。

2.4 AgentOps、可靠性与治理

第五条路线关注 Agent 的运行、监控与治理。AgentOps 研究提出覆盖 Agent 全生命周期的可观测性分类，明确应当追踪的制品与数据 [15]；另一项综述把 Agent 运维分为监控、异常检测、根因分析和修复四个阶段 [16]。Moshkovich 和 Zeltyn 从开发者、测试者、站点可靠性工程师和业务用户四类角色出发，提出六阶段自动化运维流水线 [18]。Cemri 等人对 1600 余条多智能体轨迹进行标注，归纳出 14 种失败模式和 3 个类别，并指出系统设计、Agent 间错位和任务验证是主要失败来源 [14]。这些工作说明，Agent 的失败往往不是单点模型错误，而是系统设计、协作协议和验证机制共同作用的结果。

治理层面，NIST AI 风险管理框架提出 Govern、Map、Measure、Manage 四个核心功能 [27]；ISO/IEC 42001 为组织建立 AI 管理体系提供要求 [28]；欧盟《人工智能法案》对高风险 AI 系统提出人类监督等义务 [29]。这些标准给出了“应当做什么”，但落地仍需要可操作的工程制品。HACF 的契约、风险路由、同意完整性门控和协作账本可以分别映射到治理、映射、测量和管理活动，但本文不声称 HACF 本身构成合规认证。

与 AgentOps 相比，HACF 的区别在于把可观测性从“事后诊断”推进到“事前与事中决策”：日志和指标不仅用于解释失败，也用于选择协同模式、触发升级和更新审批策略。与治理标准相比，HACF 提供的是一套可实现的运行时机制，而不是原则性要求。本文不主张 HACF 能解决所有 Agent 安全问题；它处理的是一类特定但重要的问题：当 Agent 的动作具有外部副作用、且组织需要明确授权与问责时，如何把人的判断嵌入执行循环。

3 Method

3.1 Problem Formulation

3.1.1 系统与任务

设企业智能体系统为

$$S=(\mathcal{M},\mathcal{T},\mathcal{W},\mathcal{H},\Pi ),$$

其中 (\mathcal{M}) 为可调用的模型集合，(\mathcal{T}) 为工具集合，(\mathcal{W}) 为共享工作区（文件、数据库、业务系统的可操作视图），(\mathcal{H}) 为具有不同角色与权限的人类集合，(\Pi) 为组织策略集合（访问控制、数据边界、职责分离、保留期限等）。一个用户请求 (x) 经过契约编译后得到任务契约

$$C=(g,{\mathcal{A}}_C,\rho ,\beta ,\epsilon ,\sigma ,{\tau }_{\max }),$$

其中 (g) 为目标，(\mathcal{A}C \subseteq \mathcal{A}) 为契约允许的动作集合，(\rho) 为风险策略，(\beta) 为风险预算，(\varepsilon) 为完成所需的证据要求，(\sigma) 为数据与权限范围，(\tau{\max}) 为契约有效期。契约不是提示词的附属说明，而是运行时检查的约束对象；任何超出 (\mathcal{A}_C) 或 (\sigma) 的动作都必须经过显式的范围扩展流程。

在时刻 (t)，系统状态记为 (s_t = (g, h_t, w_t, b_t, C))，其中 (h_t) 为交互历史，(w_t) 为工作区状态，(b_t) 为剩余预算。Agent 策略 (\pi_\theta) 根据 (s_t) 提议动作

$$a_t=({\mathrm{tool}}_t,{\mathrm{args}}_t)\in \mathcal{A}.$$

动作可能读取数据，也可能改变外部状态。本文把后者称为副作用动作；只有副作用动作才需要进入审批门控的风险评估，读取动作则依据数据敏感度进入不同的访问控制路径。

3.1.2 风险表示

每个动作被映射为风险向量

$$r(a)=(s(a),x(a),v(a),u(a)),$$

其中 (s(a)\in[0,1]) 表示利害程度（金额、法律后果、安全影响、客户影响等），(x(a)\in{0,1}) 表示外部可见性（是否发送到组织外部、是否面向客户或公众），(v(a)) 表示可逆性，(u(a)\in[0,1]) 表示不确定性（模型置信度、工具可靠性、上下文歧义、跨系统依赖等）。可逆性类别定义为

κ ( a ) ∈ { I d e m ,   R e v ,   C o m p ,   I r r } , \kappa(a) \in \{\mathrm{Idem},\, \mathrm{Rev},\, \mathrm{Comp},\, \mathrm{Irr}\}, κ(a)∈{Idem,Rev,Comp,Irr},

分别对应幂等、可逆、可补偿和不可逆四类。幂等动作重复执行不改变结果，例如查询；可逆动作可以通过逆操作恢复，例如创建可撤销的草稿；可补偿动作不能完全撤销，但可以通过后续操作补偿，例如发送通知后致歉、退款后追回；不可逆动作无法恢复原状，例如删除生产数据、对外付款、公开发布内容。该分类借鉴 Zhai 等人对 Agent 执行可逆性的形式化 [24]，但本文把它用于协同模式选择，而不是用于流式修订算法。

风险分数由校准模型给出：

$$R(a)=\sigma \left(w^{\top }\varphi (r(a))+b\right),$$

其中 (\phi(\cdot)) 为特征变换，(w) 和 (b) 为可学习参数，(\sigma(\cdot)) 为把实数映射到 ([0,1]) 的函数。(R(a)) 应被解释为“在给定上下文下，该动作造成策略违规或严重伤害的校准风险分数”，而不是客观概率。风险分数必须经过校准评估；若校准不足，系统应对高风险动作采取保守回退，而不是依赖未校准的分数。

3.1.3 协同模式与人类决策

设协同模式集合为

M c o l l a b = { M 0 , M 1 , M 2 , M 3 } , \mathcal{M}_{\mathrm{collab}} = \{M_0, M_1, M_2, M_3\}, Mcollab​={M0​,M1​,M2​,M3​},

分别表示自主执行、监督执行、协同执行和升级接管。人类在时刻 (t) 的决策记为

d t ∈ D = { approve ,  approve-scope ,  edit ,  reject-action ,  reject-plan ,  takeover } . d_t \in \mathcal{D} = \{\text{approve},\ \text{approve-scope},\ \text{edit},\ \text{reject-action},\ \text{reject-plan},\ \text{takeover}\}. dt​∈D={approve, approve-scope, edit, reject-action, reject-plan, takeover}.

其中 approve 表示批准当前动作一次，approve-scope 表示在明确范围内批准一类动作，edit 表示修改动作参数后批准，reject-action 表示拒绝当前动作但保留计划，reject-plan 表示拒绝整个计划，takeover 表示由人类接管后续执行。把“拒绝动作”和“拒绝计划”分开很重要：前者允许 Agent 换一种方式完成同一目标，后者要求重新规划；混淆两者会导致系统错误地重试被否决的路径。

3.1.4 优化目标与约束

设任务效用为 (U(s_t,a_t))，伤害为 (H(s_t,a_t))，提交给人类的审批请求为 (q_t)，人类决策成本为 (c(q_t))。协同策略 (\mu) 根据状态、动作和风险选择模式，Agent 策略 (\pi) 提议动作。系统的目标可以写为

$$\underset{\mu ,\pi }{\max }\mathbb{E}\left[\sum _{t=0}^T(U(s_t,a_t)-\lambda H(s_t,a_t)-\gamma c(q_t))\right],$$

约束为

$$\mathrm{Pr}\left(\exists t:H(s_t,a_t)\ge H_{\max }\right)\le \delta ,$$

$$\mathbb{E}\left[\sum _{t=0}^{T}c(q_t)\right]\le B_H,$$

$$\mathrm{AuditCompleteness}(\tau )\ge \eta ,$$

其中 (\lambda,\gamma>0) 为权衡系数，(H_{\max}) 为严重伤害阈值，(\delta) 为可接受的风险上界，(B_H) 为人类注意力预算，(\eta) 为审计完整性下界。该目标不是要求系统自动求解一个全局最优策略，而是为设计选择提供明确的权衡语言：安全约束、人工负担约束和审计约束不能被任务效用无限度交换。

3.1.5 设计需求

由上述形式化，本文提出五项设计需求。

• D1 范围保真：Agent 只能执行契约允许的动作；范围扩展必须显式记录并经人类确认。
• D2 风险相称：监督强度与动作风险匹配；低风险动作不应被无差别审批，高风险动作不应被静默放行。
• D3 同意完整：人类批准的内容必须忠实对应实际执行的动作；批准范围、批准人和有效期必须可验证。
• D4 审计可回放：关键事件必须形成可验证、可重放的记录；记录缺失应导致高风险动作失败关闭（fail-closed）。
• D5 受约束适应：系统可以从人工决策中学习，但学习不得突破安全约束，也不得把重复批准自动解释为长期偏好。

表 1 汇总了本节使用的主要符号。

表 1 主要符号

符号	含义
(S)	企业智能体系统
(x)	用户请求
(g)	任务目标
(C)	任务契约
(\mathcal{A}_C)	契约允许的动作集合
(\sigma)	数据与权限范围
(\rho)	风险策略
(\beta)	风险预算
(\varepsilon)	完成所需的证据要求
(s_t)	时刻 (t) 的系统状态
(a_t)	时刻 (t) 提议的动作
(r(a))	动作风险向量
(\kappa(a))	可逆性类别
(R(a))	校准后的风险分数
(m_t)	协同模式
(d_t)	人类决策
(q_t)	提交给人类的审批请求
(c(q_t))	人类决策成本
(U)	任务效用
(H)	伤害
(\mathcal{L})	协作账本

3.2 Framework Overview

HACF 采用分层结构，如图 1 所示。最上层是组织治理面，负责身份、权限、数据边界、职责分离和服务等级；中间是 HACF 运行时，包含契约编译、风险路由、协同执行、同意完整性门控、人工容量调度、证据绑定和协作账本；最下层是 Agent 运行时，包含规划器、工具调用、记忆、验证器和沙箱。HACF 不替代 Agent 运行时，而是在其与组织系统之间插入一层可检查的协同协议。

┌──────────────────────────────────────────────────────────────────────┐
│ 组织治理面：RBAC/ABAC · 数据边界 · 职责分离 · 双人复核 · SLA/SLO      │
└───────────────────────────────┬──────────────────────────────────────┘
                                │ 策略、配额与身份
┌───────────────────────────────▼──────────────────────────────────────┐
│ HACF 运行时                                                           │
│                                                                      │
│  ┌──────────────┐    ┌──────────────┐    ┌────────────────────────┐  │
│  │ 任务契约编译 │───▶│ 风险感知路由 │───▶│ 协同执行引擎           │  │
│  │ Contract     │    │ Risk Router  │    │ M0 自主 / M1 监督      │  │
│  │ Compiler     │    │              │    │ M2 协同 / M3 升级      │  │
│  └──────┬───────┘    └──────┬───────┘    └───────────┬────────────┘  │
│         │                   │                        │               │
│  ┌──────▼───────┐    ┌──────▼───────┐    ┌───────────▼────────────┐  │
│  │ 证据绑定器   │    │ 同意完整性   │    │ 人工容量调度器         │  │
│  │ Evidence     │    │ 门控 Gate    │    │ Capacity Scheduler     │  │
│  └──────┬───────┘    └──────┬───────┘    └───────────┬────────────┘  │
│         │                   │                        │               │
│  ┌──────▼───────────────────▼────────────────────────▼────────────┐  │
│  │ 协作账本 Collaboration Ledger：事件 · 证据 · 批准 · 回滚 · 签名 │  │
│  └───────────────────────────────┬────────────────────────────────┘  │
└──────────────────────────────────┼───────────────────────────────────┘
                                   │ 审计、回放、反馈
┌──────────────────────────────────▼───────────────────────────────────┐
│ Agent 运行时：规划器 · 工具调用 · 记忆 · 验证器 · 沙箱              │
└──────────────────────────────────────────────────────────────────────┘

图 1 HACF 总体架构。 组织治理面向 HACF 提供策略与配额；HACF 在 Agent 运行时与业务系统之间承担契约、路由、门控、调度和审计职责。

图 1 中的箭头方向体现了 HACF 的一个基本设计选择：审批不是 Agent 内部的一步，而是 Agent 运行时与组织治理面之间的协议交互。Agent 可以提议动作，但不能自行生成批准令牌；批准令牌由门控在独立渲染后生成，并由执行监视器在动作真正落地前校验。这一分工使“Agent 自述”和“组织授权”在结构上分离。

图 2 给出协同模式的状态转换。路由器先判断动作是否低风险且高可逆，再判断是否处于中等风险且非不可逆，最后判断是否外部可见或不可逆；无法满足自主或监督条件的高风险动作进入协同执行，极高风险或政策冲突进入升级接管。该图是设计规则，不是学习得到的黑箱策略；阈值和特征权重可以按租户校准，但状态转换的语义保持稳定。

                    ┌──────────────────────────────┐
                    │ 动作提议 a_t                 │
                    └──────────────┬───────────────┘
                                   │ 风险评估
                    ┌──────────────▼───────────────┐
                    │ R(a_t) < τ1 且 κ 为 Idem/Rev？│
                    └───────┬───────────────┬──────┘
                        是  │               │ 否
                    ┌───────▼──────┐  ┌─────▼────────────────────┐
                    │ M0 自主执行  │  │ R(a_t) < τ2 且非 Irr？   │
                    └──────────────┘  └─────┬──────────────┬─────┘
                                         是 │              │ 否
                                    ┌───────▼──────┐  ┌────▼─────────────┐
                                    │ M1 监督执行  │  │ 外部可见或不可逆？│
                                    └──────────────┘  └────┬──────────┬──┘
                                                        是 │          │ 否
                                                   ┌───────▼──────┐ ┌─▼────────────┐
                                                   │ M2 协同执行  │ │ M3 升级接管  │
                                                   └──────────────┘ └──────────────┘

图 2 协同模式状态转换。 (M_0) 为自主执行，(M_1) 为监督执行，(M_2) 为协同执行，(M_3) 为升级接管；(\tau_1<\tau_2) 为租户可配置的风险阈值。

HACF 的设计原则可以概括为八条。

• P1 契约先行：没有明确契约，不执行有副作用的动作。
• P2 风险相称：监督强度随风险变化，而不是对所有动作一视同仁。
• P3 同意完整：人类批准的是规范化动作，不是 Agent 的自述。
• P4 可逆优先：优先选择可逆或可补偿的动作；不可逆动作前必须设置检查点。
• P5 证据绑定：任务完成需要可核验的证据，而不是 Agent 的自我报告。
• P6 审计默认：关键事件默认写入账本；账本不可用时高风险动作失败关闭。
• P7 容量感知：审批路由考虑人工队列、服务等级和认知负担，避免把安全责任转化为审批疲劳。
• P8 受约束学习：人工决策可以改进路由，但不能突破安全约束，也不能把重复批准自动视为长期授权。

3.3 Module Details

3.3.1 Task Contract Compiler

契约编译器负责把用户请求转化为结构化契约。它的输入包括自然语言请求、用户身份、租户策略、数据边界、可用工具、预算和截止时间；输出为 3.1 节定义的 (C)。表 2 给出契约的主要字段。

表 2 任务契约字段

字段	说明	设计要点
goal	任务目标	用可验证的完成条件描述，避免“尽量做好”等模糊表述
non_goals	明确不做的事项	防止范围蔓延和过度授权
allowed_tools	允许调用的工具	按工具、资源、参数范围限定
forbidden_actions	禁止动作	与租户策略合并，优先级高于 Agent 计划
data_scope	可访问的数据范围	记录数据类别、租户、地域和保留期限
risk_budget	可接受的风险预算	包括单动作阈值和任务累计阈值
evidence_requirements	完成所需证据	例如测试报告、审批记录、对账结果、变更单
success_criteria	成功判定	由独立验证器或指定人类角色确认
escalation_contacts	升级联系人	按风险类型和责任域路由
expires_at	契约有效期	过期后自动失效，防止长期悬挂授权

契约编译包含五个步骤。第一，意图解析：抽取目标、对象、范围、时间、金额、数据类别等结构化要素。第二，策略检索：从组织策略中检索与任务相关的访问控制、数据边界、职责分离和监管要求。第三，范围扩展检查：判断用户请求是否隐含超出其权限的动作；若存在，生成显式的范围扩展请求，而不是静默扩权。第四，歧义检测：识别目标、对象或成功标准中的歧义；系统可以生成澄清问题，也可以采用保守解释并把假设写入契约。第五，契约验证：检查字段完整性、策略一致性和工具可用性；验证失败的契约不得进入执行阶段。

契约编译器必须遵循“禁止静默扩权”原则。若用户说“帮我处理一下这个季度的报销”，系统不能自行推断“处理”包括提交付款、修改银行账户或删除历史记录；它应把目标限定为可验证的子任务，并把高风险动作列为待确认项。若系统选择保守解释，必须在契约中记录假设，并在执行前向用户展示。该原则直接对应 D1 范围保真。

契约还具有生命周期。草稿状态允许修改；确认后进入活动状态；任务完成、超时或被撤销后进入终止状态。撤销必须传播到运行时：正在排队的动作被取消，正在执行的不可逆动作进入回滚或升级流程，账本记录撤销事件。契约版本与策略版本一起写入账本，确保事后可以判断“当时的授权依据是什么”。

3.3.2 Risk-aware Router

风险路由器的任务是把动作映射到协同模式。它不是简单的规则引擎，也不是完全端到端的黑箱分类器，而是“可解释规则 + 校准模型 + 保守回退”的组合。规则部分保证高风险动作不会被模型错误地放行；模型部分负责在规则未覆盖的长尾情境中提供风险估计；回退部分保证在信息不足时选择更保守的模式。

路由器使用 3.1.2 节的风险向量，并可以加入以下特征：数据敏感度、权限等级、影响范围（单条记录、单用户、全租户）、工具可靠性、调用链深度、是否跨租户、是否涉及资金或法律义务、是否存在提示注入迹象。风险分数 (R(a)) 可以由梯度提升树、逻辑回归或小型校准网络给出；无论使用何种模型，都必须报告校准误差和分群误差，而不能只报告 AUC。

路由规则可以写为

m t = { M 3 , κ ( a t ) = I r r   ∧   ( s ( a t ) ≥ s H   ∨   x ( a t ) = 1 ) , M 2 , κ ( a t ) ∈ { C o m p , I r r }   ∨   x ( a t ) = 1   ∨   R ( a t ) ≥ τ 2 , M 1 , R ( a t ) ≥ τ 1 , M 0 , otherwise , m_t = \begin{cases} M_3, & \kappa(a_t)=\mathrm{Irr}\ \land\ \big(s(a_t)\ge s_H\ \lor\ x(a_t)=1\big),\\[4pt] M_2, & \kappa(a_t)\in\{\mathrm{Comp},\mathrm{Irr}\}\ \lor\ x(a_t)=1\ \lor\ R(a_t)\ge \tau_2,\\[4pt] M_1, & R(a_t)\ge \tau_1,\\[4pt] M_0, & \text{otherwise}, \end{cases} mt​=⎩ ⎨ ⎧​M3​,M2​,M1​,M0​,​κ(at​)=Irr ∧ (s(at​)≥sH​ ∨ x(at​)=1),κ(at​)∈{Comp,Irr} ∨ x(at​)=1 ∨ R(at​)≥τ2​,R(at​)≥τ1​,otherwise,​

其中 (s_H) 为高利害阈值，(\tau_1<\tau_2) 为风险阈值。该规则体现三个保守性选择。第一，不可逆且高利害或外部可见的动作至少进入协同执行，必要时升级接管。第二，可补偿动作默认进入协同执行，因为补偿本身可能产生二次伤害。第三，任何外部可见动作都不进入完全自主模式，即使模型置信度很高。规则中的阈值由租户策略设定，并可通过历史事件校准；但规则的结构不随模型更新而改变。

表 3 四种协同模式

模式	人类介入时点	适用条件	人类职责	主要风险
(M_0) 自主执行	无	低风险、可逆、可验证	事后抽样审计	长尾错误、分布漂移
(M_1) 监督执行	执行后、提交前	中风险、可逆或可补偿	审查证据与结果	复核遗漏、形式化签字
(M_2) 协同执行	执行前	高风险、外部可见、不可逆	批准、编辑或拒绝具体动作	审批疲劳、上下文不足
(M_3) 升级接管	执行前或执行中	极高风险、政策冲突、连续失败	接管规划或联合决策	响应延迟、责任不清

表 3 中的 (M_3) 不是失败路径，而是设计路径。企业系统中总存在 Agent 不应独立处理的决策，例如涉及重大资金、法律承诺、人事处分或安全事件的动作。将这些决策显式路由到人类，比让 Agent 在不确定中“尽量完成”更符合组织治理逻辑。关键在于 (M_3) 必须附带足够的上下文、备选方案和截止时间，否则升级会变成把问题原样抛回给人。

风险路由器还需要处理分布漂移。模型更新、工具变更、组织策略调整和业务季节性都可能改变风险分布。系统应监控路由结果与实际事件的一致性，定期重新校准风险分数，并在检测到漂移时收紧阈值。收紧阈值会增加人工负担，因此需要与容量调度器联动；但安全约束优先于效率约束。

3.3.3 Consent-Integrity Gate

同意完整性门控是 HACF 的核心安全组件。它解决的不是“要不要审批”，而是“人类到底在批准什么”。门控包含四个步骤：规范化、独立渲染、绑定批准、执行前校验。

步骤一：规范化。 Agent 提议的动作被转换为规范形式。规范形式至少包含：工具名称与版本、规范化参数、目标资源标识、数据流出方向、预期副作用、可逆性类别、回滚计划、风险解释和证据引用。参数规范化需要处理默认值、路径归一化、单位统一、编码转义和等价写法；否则攻击者可以利用“看起来不同、执行起来相同”的参数绕过哈希校验。规范化后的动作记为 (\hat{a})。

步骤二：独立渲染。 审批界面不能由 Agent 生成的自然语言摘要直接渲染，而应由门控从 (\hat{a}) 生成结构化视图。视图应突出人类做决定所需的信息：将要改变什么、影响哪些对象、是否对外可见、能否撤销、最坏后果是什么、有哪些更安全的替代方案。Agent 可以提供解释，但解释只能作为附注，不能替代结构化事实。该设计直接回应了同意完整性问题 [26]：批准界面必须由可信中介从真实动作渲染，而不是信任 Agent 的自述。

步骤三：绑定批准。 人类决策被编码为批准令牌。令牌至少包含：动作哈希 (H(\hat{a}))、动作范围、批准人身份、批准时间、过期时间、随机数、策略版本和签名。批准令牌与具体动作绑定；若动作参数在执行前发生变化，哈希不匹配，令牌失效。对于范围化批准，令牌记录范围条件，例如“允许在本次任务内创建不超过 10 个测试账户”，执行监视器在每次动作前检查条件是否满足。

步骤四：执行前校验。 执行监视器在动作真正落地前重新计算 (H(\hat{a}))，并检查批准令牌是否有效、是否在范围内、是否未过期、批准人是否有权限。校验失败时，动作被阻断，账本记录违规事件，系统根据风险等级选择重试、重新审批或升级。对于不可逆动作，校验失败必须失败关闭，不能降级为“先执行后补批”。

门控的接受条件可以写为

$$\mathrm{Accept}(a)=1[H(\hat{a})=H({\hat{a}}_{\mathrm{appr}})]\wedge \mathrm{within}(a,{\sigma }_{\mathrm{appr}})\wedge \mathrm{auth}(u_{\mathrm{appr}},a)\wedge \neg \mathrm{expired}(\mathrm{token}),$$

其中 (\hat{a}{\mathrm{appr}}) 为被批准的动作，(\sigma{\mathrm{appr}}) 为批准范围，(u_{\mathrm{appr}}) 为批准人。该条件只保证“执行的动作与批准的动作一致”，不保证“批准本身是正确的”。后者取决于人类判断、信息呈现质量和组织培训，属于残余风险。

图 3 给出门控的数据流。

Agent 提议 ──▶ 规范化动作 ──▶ 独立渲染 ──▶ 人类决策 ──▶ 批准令牌
                   │              │             │            │
                   │              │             │            ▼
                   │              │             │      执行监视器校验
                   │              │             │   H(action)=H(approved)?
                   │              │             │      范围/权限/时效?
                   │              │             │            │
                   └──────────────┴─────────────┴──▶ 协作账本（哈希链）

图 3 同意完整性门控。 规范化、渲染、批准和执行校验四个步骤共享同一动作哈希；任何一步的信息不一致都会导致执行阻断。

门控还需要处理审批疲劳。HACF 采用四种策略，但不以牺牲不可逆动作的安全性为代价。第一，按风险排序队列：高风险、临近截止时间的请求优先展示。第二，可逆动作批处理：对同一任务内语义相近、可撤销的动作，可以合并为一次审批，但界面必须展示批内每个动作的摘要和数量。第三，范围化批准：对重复性低风险动作，允许在明确时间、数量和资源范围内批准，而不是逐次弹窗；范围化批准不适用于不可逆动作。第四，拒绝语义区分：允许人类拒绝单个动作但保留计划，或拒绝整个计划；系统不应把“拒绝动作”误解为“拒绝目标”，也不应把重复批准自动解释为长期偏好。

对于高价值不可逆动作，门控应支持双人复核（two-person rule）和职责分离：请求者、批准者和执行者不能是同一人；第二批准人应看到第一批准人的决定和理由。该机制增加人工成本，但适用于资金支付、生产数据删除、权限变更等场景。门控还应提供“编辑后批准”：人类可以直接修改参数或选择更安全的替代方案，修改后的动作重新规范化、重新计算哈希并重新绑定批准。

3.3.4 Collaboration Ledger

协作账本记录任务生命周期中的关键事件，为审计、回放、事件调查和反馈学习提供依据。账本不是普通日志，而是带有结构、顺序和完整性证明的事件流。每条事件至少包含：事件标识、任务标识、租户标识、时间戳、参与者及其类型、事件类型、状态哈希、动作哈希、策略版本、证据引用、批准令牌哈希、执行结果、前序哈希和签名。

账本采用哈希链：

$$h_i=H(h_{i-1}\Vert \mathrm{canonical}(e_i)),h_0=H(\mathrm{genesis}),$$

其中 (e_i) 为第 (i) 条事件，(H) 为抗碰撞哈希函数（例如 SHA-256），(\mathrm{canonical}(\cdot)) 为确定性序列化。系统定期对链头签名，形成检查点。验证者只需信任检查点签名，就可以检测历史事件是否被篡改。该性质是标准哈希链性质，本文不声称它是新的密码学结果；HACF 的贡献是把该结构用于人机协同事件的记录与回放。

账本支持三类查询。第一，任务回放：按时间顺序重建契约、计划、动作、审批、执行和验证过程，判断失败发生在哪个环节。第二，授权审计：回答“谁在什么时间、基于什么证据、批准了哪个动作、批准范围是什么”。第三，策略评估：统计不同风险等级下的批准率、拒绝率、编辑率、回滚率和事故率，为阈值调整提供依据。

账本必须处理隐私与保留期限。审批记录可能包含个人信息、商业秘密和敏感业务数据；系统应只把必要的结构化字段写入链上，把大对象存入受控存储，并在链上记录内容承诺（commitment）而非明文。不同租户的数据应逻辑隔离；跨租户查询需要显式授权。保留期限到期后，系统可以删除明文，但保留哈希承诺和审计元数据，以维持可验证性。账本写入失败时，高风险动作必须失败关闭；低风险动作可以降级为本地缓冲，但必须在恢复后补写并标记延迟。

3.3.5 Human Capacity Scheduler

人工容量调度器把审批请求路由到合适的人，并管理队列、服务等级和认知负担。它解决的问题是：安全机制不能假设人类注意力无限；如果审批队列过长，人会加速点击，审批质量下降，安全机制反而失效。

调度器维护每个审批者的角色、权限、当前负载、历史决策质量和可用时间。请求的优先级可以写为

$$\pi (q)=\alpha \mathrm{risk}(q)+\beta \mathrm{urgency}(q)+\gamma \mathrm{SLA}(q)-\delta \mathrm{load}(u),$$

其中 (\mathrm{risk}(q)) 为风险分数，(\mathrm{urgency}(q)) 为截止时间压力，(\mathrm{SLA}(q)) 为服务等级违约风险，(\mathrm{load}(u)) 为审批者当前负载，(\alpha,\beta,\gamma,\delta) 为权重。该公式只用于排序，不用于自动批准；高风险请求即使队列拥堵也不能被静默放行，只能升级或等待。

调度器应支持批处理，但批处理有明确边界。设一批包含 (k) 个动作，批处理成本可以近似为

$$C_{\mathrm{batch}}=c_b+k{c}_a,$$

其中 (c_b) 为批次切换成本，(c_a) 为单动作审查成本。当 (c_b < (k-1)c_a) 时，批处理减少总时间；但它不能减少需要审查的动作数量。对于不可逆动作，批处理只能用于信息展示，不能合并批准；每个不可逆动作仍需要独立的批准令牌。该结论对应 3.5 节的审批负载分解。

调度器还需要处理“审批疲劳”的早期信号：审批时间过短、批准率异常升高、拒绝后立即重试、同一用户连续批准高风险动作、审批者长时间在线。系统可以把这些信号反馈给治理面板，触发复核、轮岗或培训，而不是简单地增加弹窗数量。

3.3.6 Constrained Feedback Learning

反馈学习模块利用人工决策和事后结果改进风险路由、审批呈现和契约模板。可用信号包括：批准/拒绝/编辑、决策时间、审批者注释、执行后验证结果、回滚事件、事故报告和用户满意度。学习目标不是最大化批准率，也不是最小化提示次数，而是在满足安全约束的前提下降低人工负担和提高任务成功率。

形式化地，设策略参数为 (\theta)，学习问题可以写为

$$\underset{\theta }{\max }{\mathbb{E}}_{{\pi }_{\theta }}[U]\text{s.t.}{\mathbb{E}}_{{\pi }_{\theta }}[H]\le \delta ,{\mathbb{E}}_{{\pi }_{\theta }}[C_{\mathrm{human}}]\le B_H.$$

具体算法可以是约束策略优化、带安全约束的上下文 bandit，或基于规则的阈值更新；本文不限定具体算法。关键在于约束是硬性的：任何提高自主性的更新都必须通过安全评估，不能因为“最近没有出事”就放宽不可逆动作的门控。

学习模块设置四条护栏。第一，不可逆动作不可学习自动批准：无论历史批准率多高，不可逆动作都必须经过显式批准或双人复核。第二，重复批准不等于长期偏好：Salerno 等人的研究表明，实践者的审批行为受时间压力、信任和情境影响 [20]；系统不能把“用户连续点了十次允许”解释为“用户永久授权此类动作”。第三，策略变更需人类批准：阈值、规则和契约模板的修改应经过治理角色审批，并记录版本。第四，漂移与公平性监控：监控不同租户、角色、任务类型和人群的误判率，避免学习放大既有偏差。

反馈学习还应区分“决策信号”和“结果信号”。人工批准是决策信号，不代表动作正确；执行后验证和事故报告才是结果信号。系统应优先使用结果信号校准风险模型，把决策信号用于改进信息呈现和队列排序。若只使用决策信号，系统可能学会迎合审批者的习惯，而不是降低真实风险。

3.4 Workflow and Algorithms

算法 1 给出 HACF 的单任务执行流程。该算法是示意性的，省略了并发、重试和分布式事务细节，但保留了关键的安全检查顺序。

算法 1  HACF 单任务协同流程
输入: 用户请求 x, 租户策略 Π, 人类池 H
输出: 任务结果、证据包、账本记录

 1: C ← CompileContract(x, Π, user)          // 契约编译与校验
 2: if C is invalid or ambiguous then
 3:     request clarification or use conservative defaults
 4: end if
 5: P ← Agent.plan(C)                        // 生成带预期动作的计划
 6: for each planned step do
 7:     annotate risk vector r(a), reversibility κ(a)
 8: end for
 9: t ← 0
10: while not Done(C) and t < T_max do
11:     a_t ← Agent.propose(s_t, P)
12:     if a_t violates C.allowed_tools or C.data_scope then
13:         trigger scope expansion or reject action
14:         continue
15:     end if
16:     R_t ← CalibratedRisk(a_t, s_t)
17:     m_t ← Router(R_t, κ(a_t), x(a_t), C)
18:     if m_t = M0 then
19:         execute(a_t) with sandbox and monitor
20:     else if m_t = M1 then
21:         execute(a_t) with checkpoint; enqueue review(a_t)
22:     else if m_t = M2 then
23:         q_t ← RenderGate(canonical(a_t), evidence, alternatives)
24:         d_t ← Human.decide(q_t)
25:         if d_t ∈ {approve, approve-scope, edit} then
26:             token ← BindApproval(canonical(a_t), d_t, approver, scope)
27:             execute_with_token(a_t, token)
28:         else if d_t = reject-plan then
29:             P ← Agent.replan(C, feedback=d_t)
30:         else
31:             mark step rejected; continue
32:         end if
33:     else
34:         handover ← PrepareHandover(s_t, a_t, evidence, alternatives)
35:         d_t ← Human.takeover(handover)
36:     end if
37:     ledger.append(event, state_hash, action_hash, evidence, token_hash)
38:     if verification_failed(a_t) or policy_violation(a_t) then
39:         rollback_or_escalate(a_t, severity=high)
40:     end if
41:     t ← t + 1
42: end while
43: evidence ← EvidenceBinder.collect(C.ε)
44: if Verify(C, evidence) then
45:     ledger.append(completion, evidence)
46:     return success
47: else
48:     ledger.append(incomplete, evidence)
49:     return needs_human_review
50: end if

算法 1 中有三个顺序值得强调。第一，契约检查先于风险评估：一个动作即使风险分数很低，只要超出契约范围，也不能执行。第二，风险评估先于模式选择：模式不是由 Agent 自报，而是由路由器根据动作和状态决定。第三，账本写入位于执行之后但验证之前：对于不可逆动作，批准记录应在执行前写入，执行结果在验证后追加；若账本不可用，不可逆动作失败关闭。算法中的 execute_with_token 必须在执行前再次校验令牌，不能只依赖第 25 行的决策。

表 4 给出异常处理规则。异常处理的核心原则是“高风险失败关闭、低风险可恢复、所有异常留痕”。

表 4 异常处理规则

异常	检测信号	处理策略
工具调用失败	超时、返回码、异常栈	有限重试；仍失败则降级或升级
证据不足	验证器无法确认完成条件	拒绝提交；补充证据或转人工复核
策略冲突	策略引擎返回冲突	阻断动作；升级法务、安全或合规角色
审批超时	队列超过 SLA	默认拒绝或升级；不得自动批准
执行后验证失败	验证器与预期不符	回滚、补偿或事件响应
账本写入失败	存储层错误	高风险动作失败关闭；低风险动作缓冲并补写
动作哈希不匹配	执行前校验失败	阻断执行；重新渲染并重新审批
连续失败	同一任务多次重试失败	升级接管；保留失败轨迹供复盘

3.5 Complexity and Theoretical Properties

3.5.1 复杂度

设任务轨迹长度为 (T)，动作平均参数规模为 (m)，风险特征维度为 (d)，审批队列长度为 (n)。契约编译的复杂度主要取决于请求长度和策略检索规模，记为 (O(|x|+|\Pi|))；风险路由为 (O(d))；动作规范化和哈希为 (O(m))；账本追加在摊销意义下为 (O(1))，链验证和回放为 (O(T))；调度器使用优先队列时为 (O(\log n))。因此，HACF 的附加开销随轨迹长度线性增长，主要成本来自人工审批和证据验证，而不是计算本身。

存储方面，账本需要保存 (O(T)) 条事件。通过内容承诺和明文分离，链上存储可以保持较小；大对象（例如文件快照、测试日志）存入受控对象存储，并在链上记录哈希和访问策略。保留期限和租户隔离会进一步影响存储设计，但不改变渐近复杂度。

3.5.2 性质

命题 1（不可逆动作的授权一致性） 假设：(i) 执行监视器在每次不可逆动作执行前重新计算规范化动作哈希；(ii) 批准令牌由独立渲染器生成，并绑定该哈希、批准人、范围和有效期；(iii) 账本在执行前持久化批准记录。则任何被执行的不可逆动作，要么与一个有效批准令牌匹配，要么被监视器阻断并记录为策略违规。

证明思路：对动作序列进行归纳。基例：若第一个不可逆动作执行，则由 (i) 和 (ii) 可知执行前存在哈希匹配的令牌；否则监视器阻断。归纳步：假设前 (t-1) 个动作满足性质；对于第 (t) 个不可逆动作，执行路径只有两种——通过执行前校验，或未通过而被阻断。通过校验意味着令牌的动作哈希与当前动作一致，且范围、权限和时效均有效；未通过则被阻断并记录。因此不存在“既执行又无有效批准”的不可逆动作。该命题不保证人类批准本身正确；残余风险来自人类判断错误、策略配置错误、渲染器实现漏洞或签名密钥泄露。它保证的是“执行动作与批准动作的一致性”，而非“批准决策的最优性”。

命题 2（审批负载分解） 设任务轨迹中需要人工决策的动作集合为 (\mathcal{Q})，批大小为 (k)。若批处理只合并提示而不合并审查，则提示次数为 (\lceil |\mathcal{Q}|/k\rceil)，但人类仍需审查 (|\mathcal{Q}|) 个动作；若不可逆动作必须逐项批准，则其审查次数下界为不可逆动作的数量。

证明思路：提示次数由分批数量决定，审查内容由动作数量决定；批处理减少的是上下文切换和界面开销，不是审查对象。不可逆动作若要求独立令牌，则每个动作至少对应一次独立决策，因此下界成立。该命题说明，降低人工负担不能依靠“把更多动作塞进一个弹窗”，而应依靠风险路由减少不必要的审批、提高信息呈现质量，以及在可逆动作上使用范围化批准。

命题 3（账本篡改可检测性） 在哈希链和签名检查点假设下，修改任一历史事件会改变该事件之后所有哈希；验证者通过检查点签名可以检测到链的不一致。

证明思路：哈希链的每条记录包含前序哈希，修改 (e_i) 会改变 (h_i)，进而改变 (h_{i+1},\dots,h_T)。若攻击者同时重写后续记录，则需要伪造检查点签名；在签名不可伪造的假设下，验证者可检测。该性质不防止“记录不完整”或“事件从未被写入”；因此 HACF 还需要写入完整性检查和失败关闭策略。

命题 4（契约范围包含） 若路由器只执行 (\mathcal{A}_C) 中的动作，且任何范围扩展都必须经过显式批准并更新契约，则不存在未经批准的超范围副作用动作。

证明思路：由算法 1 第 12–15 行，超范围动作在执行前被拦截；范围扩展路径必须更新 (C) 并留下批准记录。对轨迹归纳即可。该命题依赖契约编译器和策略引擎的正确实现；若策略本身配置错误，系统仍可能批准本不应批准的动作。因此，契约范围包含是“实现级保证”，不是“治理级保证”。

这些性质共同刻画了 HACF 的安全边界：它能把“执行与批准不一致”“超范围执行”“账本篡改”转化为可检测或可阻断的事件，但不能替代组织对风险偏好、权限配置和人类培训的治理责任。本文不声称这些性质足以覆盖所有攻击面；附录 D 给出威胁模型和剩余风险。

4 Experiments

4.1 Experimental Setup

截至本文写作时，HACF 尚未在真实企业环境中完成部署实验。本节给出可复现的实验设计、评价指标、基线、统计方案和结果记录模板；所有需要实测的数值均以 标注。这样做的目的是把设计假设转化为可检验的命题，而不是用未经测量的数字支撑结论。

4.1.1 研究问题

实验围绕五个研究问题展开。

• RQ1（安全性）：与完全自主、事后监督和统一逐动作审批相比，HACF 是否降低未经授权的不可逆动作率和严重伤害率？
• RQ2（人工负担）：在相近安全水平下，HACF 是否减少每任务提示次数和人工分钟数？
• RQ3（同意完整性）：在存在对抗性叙述或参数混淆的场景中，独立渲染与哈希绑定是否降低审批错误率？
• RQ4（路由质量）：风险感知路由是否比静态规则或单一阈值获得更高的审批精度与召回率？
• RQ5（适应性与安全性）：受约束反馈学习是否能在不提高伤害率的前提下减少不必要的审批？

4.1.2 环境与任务

实验环境采用两类设置。第一类是受控企业模拟环境，参考 TheAgentCompany 的设计 [11]，搭建内部网页、代码仓库、项目管理、文件存储、邮件和人事/财务系统；任务覆盖人力资源、财务、软件工程、行政支持和客户支持五个领域。第二类是真实工具沙箱，在隔离容器中调用真实命令行、版本控制、表格和邮件工具，用于检验环境保真度对结论的影响。两类环境都记录完整轨迹，并由独立验证器判定任务是否完成。

任务按三个维度分层：领域（5 类）、风险等级（低、中、高）、时间跨度（5–10 步、10–30 步、30 步以上）。每个单元的任务数量、任务来源和标注规范为 。风险等级由两名以上标注者独立标注，分歧通过讨论解决；标注一致性使用 Cohen’s (\kappa) 或 Krippendorff’s (\alpha) 报告，具体数值为 。任务中应包含一定比例的“越界诱饵”：用户请求未明确授权、但 Agent 可能顺带执行的高风险动作，用于测量未经授权动作率。

4.1.3 基线与消融

实验比较以下系统。

• B1 完全自主：Agent 在契约范围内自主执行，无事前审批；事后仅做抽样审计。
• B2 统一逐动作审批：所有副作用动作都弹出审批，不区分风险。
• B3 事后监督：Agent 自主执行，人类在任务提交前审查结果；高风险动作不单独拦截。
• B4 静态风险规则：按工具类型和金额阈值路由，不使用上下文、可逆性或不确定性特征。
• B5 HACF 去除同意完整性渲染：保留路由和账本，但审批界面使用 Agent 生成的摘要。
• B6 HACF 完整版：包含契约、路由、同意完整性门控、账本、容量调度和受约束反馈学习。

消融实验进一步移除单个模块：去除风险路由器、去除协作账本、去除批处理、去除双人复核、去除反馈学习、去除范围化批准。每个消融配置保持其他模块不变，以隔离各模块的贡献。

4.1.4 评价指标

设任务总数为 (N)，任务 (i) 的成功指示为 (\mathrm{succ}_i\in{0,1})。任务成功率定义为

$$\mathrm{TSR}=\frac{1}{N}\sum _{i=1}^N{\mathrm{succ}}_i.$$

严重伤害率定义为发生至少一次严重伤害事件的任务比例：

$$\mathrm{SHR}=\frac{1}{N}\sum _{i=1}^{N}1[\exists t:H(s_{i,t},a_{i,t})\ge H_{\max }].$$

未经授权不可逆动作率定义为

U I R = # { 未经授权的不可逆动作 } # { 不可逆动作 } , \mathrm{UIR} = \frac{\#\{\text{未经授权的不可逆动作}\}}{\#\{\text{不可逆动作}\}}, UIR=#{不可逆动作}#{未经授权的不可逆动作}​,

其中“未经授权”指动作超出契约范围、未获得有效批准令牌，或批准令牌与实际动作不匹配。人工介入负担用每任务提示次数和每任务人工分钟数衡量；审批质量用批准精度（AP）和召回率（AR）衡量：

$$\mathrm{AP}=\frac{TP}{TP+FP},\mathrm{AR}=\frac{TP}{TP+FN},$$

其中 (TP) 为被标记为需审批且事后被判定为高风险的动作数，(FP) 为被标记但实际低风险的动作数，(FN) 为未被标记但实际高风险的动作数。风险标签由独立评审根据任务契约、组织策略和后果严重性判定；标注规范需预先注册。

其他指标包括：平均解决时间（TTR）、审计完整性（关键事件中成功写入账本的比例）、回滚成功率（失败动作中成功恢复原状态的比例）、每成功任务成本（模型调用、工具调用和人工时间的加权和），以及审批者认知负荷（NASA-TLX 或简化量表）。所有指标的报告应包含均值、标准差或置信区间，并说明样本量。

4.1.5 人类研究设计

人类研究采用被试内设计，条件顺序按拉丁方平衡，任务集合在各条件间匹配。参与者来自企业 IT 运维、财务、人力资源、软件工程和客户支持岗位；纳入/排除标准、样本量和招募方式为 。实验任务包含正常任务和嵌入的越界/对抗场景；参与者在不知晓具体假设的情况下进行审批、编辑或拒绝。

测量包括：决策正确率、决策时间、认知负荷、信任校准、感知控制、对审批信息充分性的评分，以及事后访谈的主题编码。伦理审批、知情同意和数据脱敏方案为 [todo: 伦理审批信息待核实]。分析采用混合效应模型，把参与者和任务作为随机效应，条件作为固定效应；报告效应量、95% 置信区间和多重比较校正。定性数据采用两名编码者独立编码，报告一致性。

4.1.6 实现细节

HACF 的实现细节包括模型选择、工具沙箱、风险分类器、阈值、账本存储和调度策略。这些配置会影响结果，因此应在论文中完整报告：模型名称与版本、温度与解码参数、工具接口、沙箱隔离级别、风险特征、训练/校准数据、阈值 (\tau_1,\tau_2,s_H)、审批队列策略、账本哈希函数和签名方案。具体配置为 [todo: 实验配置待补充]。代码与数据发布方式为 [todo: 代码仓库待补充]。

4.2 Main Results

表 5 是主结果记录模板。由于尚未完成实测，表中不填写数值；任何后续填充都必须来自可复现实验，并附置信区间和样本量。

表 5 主结果记录模板

方法	TSR ↑	SHR ↓	UIR ↓	提示次数/任务 ↓	人工分钟/任务 ↓	AP ↑	AR ↑	审计完整性 ↑	每成功任务成本 ↓
B1 完全自主	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]
B2 统一逐动作审批	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]
B3 事后监督	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]
B4 静态风险规则	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]
B5 HACF 无同意完整性渲染	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]
B6 HACF 完整版	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]

与表 5 对应，实验应检验以下假设。H1：HACF 的 UIR 和 SHR 低于 B1 与 B3；H2：在相近 SHR 下，HACF 的人工分钟数低于 B2；H3：在对抗性叙述场景中，B6 的审批错误率低于 B5；H4：B6 的 AP 和 AR 高于 B4；H5：经过受约束反馈学习后，B6 的提示次数下降而 SHR 不上升。上述假设均为待检验命题，不是本文已证实的结论。

4.3 Ablation Study

表 6 给出消融实验记录模板。消融的重点不是追求某个模块的“最大贡献”，而是确认安全属性是否依赖关键机制：去除同意完整性渲染是否提高批准错误率；去除账本是否降低审计完整性；去除双人复核是否提高高价值不可逆动作的伤害率；去除风险路由是否使人工负担或伤害率上升；去除反馈学习是否使长期提示次数难以下降。

表 6 消融实验记录模板

配置	TSR ↑	SHR ↓	UIR ↓	人工分钟/任务 ↓	审计完整性 ↑	备注
HACF 完整版	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	基准
去除风险路由	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	统一审批或统一自主
去除同意完整性渲染	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	使用 Agent 摘要
去除协作账本	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	仅普通日志
去除双人复核	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	高价值动作单人批准
去除批处理	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	逐动作提示
去除反馈学习	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	[todo: 实验数据待填]	固定阈值

4.4 Analysis

4.4.1 失败模式分析

HACF 的失败可能来自多个层面。表 7 给出失败模式、检测信号和缓解措施。该表参考了多智能体失败分类 [14] 和 AgentOps 的可观测性分类 [15,16]，但针对人机协同流程进行了重新组织。

表 7 人机协同流程的失败模式

失败模式	典型表现	检测信号	HACF 缓解
范围漂移	Agent 为完成目标自行扩大权限或数据范围	动作超出 (\mathcal{A}_C)；契约外工具调用	契约检查、范围扩展审批、账本告警
审批疲劳	人类快速连续批准，决策时间趋近于零	批准时间、批准率、拒绝后重试	风险路由、批处理、容量调度、轮岗
同意错配	批准摘要与实际动作不一致	动作哈希不匹配；渲染器告警	独立渲染、哈希绑定、执行前校验
长程遗忘	多步之后偏离原始目标或约束	目标一致性检查、里程碑验证	契约重注入、检查点、阶段验收
工具失效	工具返回错误、超时或被投毒	返回码、延迟、异常分布	有限重试、降级、工具信誉
验证缺口	任务被标记完成但证据不足	证据绑定失败、独立验证不通过	证据要求、独立验证器、人工复核
策略冲突	不同租户/部门策略相互矛盾	策略引擎冲突报告	阻断、升级合规、策略版本化
多 Agent 错位	角色之间目标不一致或信息丢失	轨迹异常、重复劳动、冲突动作	共享账本、角色契约、升级机制

4.4.2 效率与人工负担

HACF 的附加成本主要来自契约编译、风险路由、门控渲染、账本写入和人工审批。计算成本通常低于人工成本；因此，效率分析应以“每成功任务的人工分钟数”和“每成功任务的总成本”为核心，而不是只看模型调用次数。风险路由的价值在于把有限的人工注意力分配到高边际价值的动作上：对低风险、可逆动作减少提示，对高风险、不可逆动作增加证据和复核。

需要注意的是，减少提示次数并不必然减少人工总时间。范围化批准和策略预写可能把决策成本前移；如果规则设置本身需要大量时间，总人工时间未必下降。Yan 的实验已经提示，预写策略在减少运行时提示的同时，可能增加规则设置成本，并且不一定提高保护水平 [23]。因此，HACF 的评估应同时报告运行时人工时间和设置/维护时间，避免把成本转移误认为成本消失。

4.4.3 定性分析

定性分析应覆盖三类材料。第一，审批轨迹：人类在哪些动作上犹豫、编辑或拒绝；拒绝后 Agent 是否改变策略；范围化批准是否被滥用。第二，访谈主题：参与者如何理解风险、信任和责任制；哪些信息帮助他们做决定；哪些界面元素造成误导。第三，失败案例：选择典型事故轨迹，逐步还原契约、路由、门控、执行和验证环节，判断失败是设计问题、实现问题还是治理问题。

定性分析不应只报告成功案例。对有代表性的失败案例，应给出完整时间线、相关证据和根因分析；若涉及敏感信息，应脱敏并说明脱敏方法。失败案例的价值在于揭示“纸面流程”和“实际执行”之间的差距，例如审批者是否真的阅读了证据、路由阈值是否被业务压力绕过、账本是否因性能问题被异步写入。

4.4.4 与相关系统的比较

表 8 从协同流程的角度比较 HACF 与典型方案。该表是定性比较，不包含性能数值。

表 8 协同流程的定性比较

维度	完全自主	统一逐动作审批	事后监督	静态风险规则	HACF
任务契约	通常无	通常无	通常无	部分有	显式契约
风险分级	无	无差别	弱	规则化	多特征校准
可逆性建模	少	少	少	少	四类显式建模
审批绑定真实动作	不适用	常依赖 Agent 摘要	不适用	常依赖摘要	哈希绑定
审计回放	弱	中	中	中	哈希链账本
人工负担控制	不适用	弱	中	中	容量感知调度
反馈学习	可能有	少	少	阈值调整	受约束学习

4.5 Limitations

本文的局限主要体现在五个方面。第一，缺少实测数据。截至写作时，HACF 尚未完成真实企业部署或大规模人类研究；本文给出的是设计、性质和实验方案，而不是性能结论。第二，环境保真度有限。企业模拟环境无法完全复现组织政治、跨部门协调、遗留系统和非结构化例外；真实部署中的协同成本可能高于模拟。第三，风险模型依赖校准。风险分数由模型和阈值共同决定；若校准数据不足或分布漂移，路由可能过度保守或过度自信。第四，人类因素复杂。审批行为受信任、时间压力、责任规避和组织文化影响；实验中的参与者行为未必能外推到真实岗位。第五，安全边界不完整。HACF 处理的是授权、执行一致性和审计问题，不覆盖模型对齐、提示注入的全部变体、供应链攻击、侧信道和内部人员合谋；这些需要与其他安全机制联合使用。

此外，HACF 引入的契约、门控和账本会增加工程复杂度和延迟。对于低风险、高吞吐的任务，完整的 HACF 流程可能不经济；实际部署应采用分级配置，例如对低风险任务只保留契约和抽样审计，对高风险任务启用完整门控和双人复核。本文不主张“一套流程适用于所有任务”，而主张“协同强度应与风险和可逆性匹配”。

5 Discussion

5.1 为什么风险相称的协同可能有效

HACF 的核心机制是把人的注意力视为有限资源，并按动作的边际风险分配。完全自主在低风险、可逆任务上效率高，但在高后果动作上缺乏保护；统一审批在高风险动作上提供了保护，却在大量低风险动作上消耗注意力，导致审批疲劳和形式化签字。风险相称的协同试图同时避免两种失败：对低风险动作减少打扰，对高风险动作增加证据、复核和问责。

这一机制的有效性取决于三个条件。第一，风险路由必须足够准确；若高风险动作被误判为低风险，系统会产生虚假的安全感。第二，审批信息必须忠实、充分；若人类看到的是 Agent 的自述而非真实动作，审批就失去意义。第三，组织必须为人类决策提供时间、权限和责任支持；若审批者没有能力或权威拒绝，门控只是把责任转移给个人。HACF 分别用校准、同意完整性和容量调度回应这三个条件，但不能替代组织治理。

5.2 适用边界

HACF 适用于以下场景：动作可观察、后果可分类、责任角色明确、组织已有基本访问控制和审计能力的企业流程。典型例子包括财务报销、采购申请、权限变更、客户数据操作、代码合并、生产变更和人事流程。对于这些场景，系统可以把任务拆分为可验证步骤，把高风险动作路由给合适角色，并用账本记录授权链。

HACF 不太适用于以下场景。第一，后果高度不确定或难以归因的开放式任务，例如战略决策、创意策划和科学研究；这些任务的风险难以用动作级特征刻画。第二，人类审批容量长期不足的场景；若没有足够的合格审批者，再好的门控也会退化为队列拥堵。第三，动作不可观察或工具链不透明的遗留系统；此时账本和证据绑定难以实现。第四，需要毫秒级响应的实时控制场景；人工介入的延迟不可接受，应优先使用形式化约束、冗余设计和自动安全机制。

5.3 伦理与组织影响

企业 Agent 的人机协同不仅是技术问题，也是劳动与治理问题。第一，工作监控：账本记录人类决策时间、批准率和拒绝理由，可能被用于绩效评估，导致审批者倾向于“快速批准”以规避风险。系统设计应限制此类数据的用途，提供聚合而非个人化的绩效视图，并允许员工申诉。第二，技能退化：如果人类长期只做“点允许”，可能失去对业务流程的判断能力；组织应保留定期人工复核、轮岗和培训。第三，责任扩散：当 Agent、审批者和组织共同导致事故时，责任边界可能模糊；契约和账本应明确每个角色的决策范围，但法律责任仍需组织与监管共同界定。第四，可及性与公平性：审批界面应支持不同语言、能力和无障碍需求；风险模型应评估不同人群和业务单元的误判率，避免系统性偏差。

HACF 的伦理立场是“增强人类判断，而不是替代或规训人类”。系统应提供可理解的信息、可比较的选项和可撤销的决定；应允许人类拒绝、编辑和接管；应把人类的决定视为有约束的判断，而不是需要被优化的标签。受约束反馈学习尤其需要防止把审批者的习惯固化为系统策略。

5.4 部署路径

企业部署 HACF 可以采用四阶段路径。第一阶段，影子模式：Agent 在后台运行，不执行真实副作用动作；系统记录其计划、风险判断和拟执行动作，与人类实际操作对比，用于校准风险模型和发现契约歧义。第二阶段，低风险自主：只对低风险、可逆、可验证的任务启用自主执行；高风险动作仍由人类执行或逐项批准。第三阶段，受监督扩展：逐步扩大自主范围，启用监督执行和范围化批准，建立审批队列、双人复核和事故响应。第四阶段，持续治理：定期审计账本、复盘失败案例、更新策略和阈值，开展红队测试和应急演练。

每一阶段都应设定明确的退出条件，例如连续若干任务无严重伤害、审计完整性达到阈值、审批精度稳定、人工负担可接受。若指标恶化，应回退到上一阶段。部署过程中应让业务、法务、安全、合规和员工代表参与，而不是由技术团队单独决定自主边界。

5.5 与治理标准的映射

表 9 给出 HACF 与 NIST AI RMF、ISO/IEC 42001 和欧盟《人工智能法案》的初步映射。该映射用于说明 HACF 制品如何支持治理活动，不构成合规认证；具体条款适用性需由法律与合规专业人员判断。

表 9 治理标准与 HACF 机制的初步映射

标准/框架	关注点	HACF 对应机制
NIST AI RMF：Govern	治理结构、责任、文化	契约、角色权限、双人复核、账本
NIST AI RMF：Map	场景、利益相关者、风险识别	任务契约、风险向量、领域标注
NIST AI RMF：Measure	风险度量、测试、监控	校准、TSR/SHR/UIR、审批精度、审计完整性
NIST AI RMF：Manage	风险响应、恢复、沟通	协同模式路由、回滚、升级、事件响应
ISO/IEC 42001	AI 管理体系、持续改进	契约版本、策略版本、反馈学习、内部审计
欧盟《人工智能法案》人类监督要求	人类有效监督、干预与停止	(M_2/M_3)、批准令牌、接管、失败关闭

6 Conclusion

本文提出 HACF，一个面向企业级 LLM Agent 系统的人机协同流程框架。HACF 把任务契约、风险感知路由、同意完整性门控、协作账本和受约束反馈学习组织为可执行的运行时流程，依据动作的利害程度、外部可见性、可逆性和不确定性，在自主执行、监督执行、协同执行和升级接管之间路由。本文给出了形式化目标、四项设计性质、模块接口、异常处理规则和可复现的评估协议，并明确区分了设计假设与待测结论。

本文不声称 HACF 已经过真实企业部署验证，也不声称它能解决所有 Agent 安全问题。它的贡献在于提供一套可讨论、可实现、可审计的协同抽象：人类批准什么、系统如何确保批准与执行一致、组织如何回放和问责、系统如何在不突破安全约束的前提下学习。对于企业而言，这套抽象可以作为渐进式授权的设计基线；对于研究而言，它给出了若干可检验的假设，例如风险相称路由能否在相近安全水平下降低人工负担、同意完整性渲染能否减少审批错误、受约束反馈学习能否在长期运行中保持安全边界。

未来工作包括四个方向。第一，在受控企业环境和真实业务沙箱中完成本文设计的实验，报告可复现的安全、效率和人工负担指标。第二，研究风险模型的跨租户校准与漂移检测，避免小众业务被系统性误判。第三，把 HACF 与 MCP、A2A 等工具/Agent 协议结合，验证跨协议场景下的同意完整性和账本一致性。第四，开展长期人类研究，观察审批疲劳、信任校准和技能退化的动态变化，并据此设计更可持续的协同界面。

References

[1] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629, 2022. ICLR 2023.

[2] Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023. NeurIPS 2023.

[3] Qingyun Wu, Gagan Bansal, Jieyu Zhang, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155, 2023.

[4] Sirui Hong, Mingchen Zhuge, Jiaqi Chen, et al. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. arXiv:2308.00352, 2023. ICLR 2024.

[5] Guanzhi Wang, Yuqi Xie, Yunfan Jiang, et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291, 2023.

[6] Xingyao Wang, Boxuan Li, Yufan Song, et al. OpenHands: An Open Platform for AI Software Developers as Generalist Agents. arXiv:2407.16741, 2024. ICLR 2025.

[7] Shuyan Zhou, Frank F. Xu, Hao Zhu, et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv:2307.13854, 2023. ICLR 2024.

[8] Tianbao Xie, Danyang Zhang, Jixuan Chen, et al. OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. arXiv:2404.07972, 2024.

[9] Carlos E. Jimenez, John Yang, Alexander Wettig, et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770, 2023. ICLR 2024.

[10] Shunyu Yao, Noah Shinn, Pedram Razavi, Karthik Narasimhan. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045, 2024.

[11] Frank F. Xu, Yufan Song, Boxuan Li, et al. TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks. arXiv:2412.14161, 2024.

[12] Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir, Arvind Narayanan. AI Agents That Matter. arXiv:2407.01502, 2024.

[13] Melissa Z. Pan, Negar Arabzadeh, Riccardo Cogo, et al. Measuring Agents in Production. arXiv:2512.04123, 2025. ICML 2026 (Oral).

[14] Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657, 2025. NeurIPS 2025 Datasets and Benchmarks Track.

[15] Liming Dong, Qinghua Lu, Liming Zhu. AgentOps: Enabling Observability of LLM Agents. arXiv:2411.05285, 2024.

[16] Zexin Wang, Jingjing Li, Quan Zhou, et al. A Survey on AgentOps: Categorization, Challenges, and Future Directions. arXiv:2508.02121, 2025.

[17] Mohamed Amine Ferrag, Norbert Tihanyi, Merouane Debbah. From LLM Reasoning to Autonomous AI Agents: A Comprehensive Review. arXiv:2504.19678, 2025.

[18] Dany Moshkovich, Sergey Zeltyn. Taming Uncertainty via Automation: Observing, Analyzing, and Optimizing Agentic AI Systems. arXiv:2507.11277, 2025.

[19] Mingchen Zhuge, Changsheng Zhao, Dylan R. Ashley, et al. Agent-as-a-Judge: Evaluate Agents with Agents. arXiv:2410.10934, 2024.

[20] Larissa Salerno, Haoyu Gao, Gregory Gay, Alexander Serebrenik, Philipp Leitner. Let the Agent Do It? How Software Practitioners Understand and Make Permission Decisions in Agentic AI Assistants. arXiv:2610.06047, 2026.

[21] Peiran Wang, Ying Li, Yuan Tian. Reframing LLM Agent Security as an Agent–Human Interaction Problem. arXiv:2605.24309, 2026.

[22] Alexandra E. Michael, Franziska Roesner. How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement. arXiv:2607.13718, 2026.

[23] Ting Yan. Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach? arXiv:2608.27443, 2026.

[24] Zhiyuan Zhai, Ming Li, Xin Wang. Revisable by Design: A Theory of Streaming LLM Agent Execution. arXiv:2604.23283, 2026.

[25] Shiva Pochampally, Shengwei An, Yan Chen. Assistant or Actor? Student Trust, Control, and Delegation Regret When Using a General-Purpose AI Agent. arXiv:2607.18257, 2026.

[26] Xiaoqi Weng. What You Approve Is What Executes: Consent Integrity for Black-Box LLM Agents. arXiv:2606.02668, 2026.

[27] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. DOI: 10.6028/NIST.AI.100-1.

[28] ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. International Organization for Standardization, 2023.

[29] European Parliament and Council of the European Union. Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act). Official Journal of the European Union, 2024.

Appendix

A. 任务契约字段示例

以下为契约的示意性 JSON 结构。字段值仅用于说明结构，不代表真实业务配置。

{
  "contract_id": "c-2026-0001",
  "tenant_id": "tenant-example",
  "goal": "为季度报销单生成核对结果并提交审批",
  "non_goals": ["修改银行账户", "删除历史报销记录"],
  "allowed_tools": [
    {"tool": "finance.read_receipt", "scope": "quarter-2026-Q3"},
    {"tool": "finance.create_draft", "scope": "user-123"}
  ],
  "forbidden_actions": ["finance.delete_record", "finance.change_bank_account"],
  "data_scope": {"classes": ["financial"], "region": "CN", "retention_days": 90},
  "risk_budget": {"per_action": 0.2, "cumulative": 0.6},
  "evidence_requirements": ["receipt_match_report", "manager_approval"],
  "success_criteria": "所有报销单完成核对，差异项有明确说明",
  "escalation_contacts": ["finance-ops", "compliance"],
  "expires_at": "2026-10-31T23:59:59Z"
}

B. 批准令牌字段示例

{
  "token_id": "t-0001",
  "task_id": "task-001",
  "action_hash": "sha256:...",
  "scope": {"type": "once", "resource": "finance.create_draft", "max_count": 1},
  "approver_id": "user-456",
  "approved_at": "2026-10-20T10:00:00Z",
  "expires_at": "2026-10-20T10:15:00Z",
  "nonce": "base64:...",
  "policy_version": "policy-2026-10-01",
  "signature": "base64:..."
}

批准令牌必须由门控服务签名，不能由 Agent 生成。执行监视器在动作落地前重新计算动作哈希，并验证签名、范围、权限和时效。对于范围化批准，scope 应包含明确的数量、资源、时间和条件；对于不可逆动作，scope.type 应为 once 或 dual，不得使用宽泛的长期范围。

C. 门控算法示意

算法 2  同意完整性门控
输入: 动作 a, 契约 C, 批准人 u, 当前策略版本 π
输出: 批准令牌 token 或拒绝原因

 1: â ← Canonicalize(a)                      // 参数归一化、资源标识、副作用
 2: if â violates C.allowed_tools or C.data_scope then
 3:     return reject("out_of_contract")
 4: end if
 5: view ← RenderIndependent(â, evidence, alternatives)
 6: d ← u.decide(view)
 7: if d = reject-action or d = reject-plan then
 8:     return reject(d)
 9: end if
10: if d = edit then
11:     â ← Canonicalize(edit(â)); goto 5       // 修改后重新渲染
12: end if
13: scope ← ScopeFromDecision(d, C)
14: if IsIrreversible(â) and not ExplicitApproval(scope) then
15:     return reject("irreversible_requires_explicit_approval")
16: end if
17: if IsHighValue(â) and not DualControl(u, scope) then
18:     return reject("dual_control_required")
19: end if
20: token ← Sign(u, H(â), scope, now, expiry, π)
21: ledger.append(approval, H(â), token.hash)
22: return token

D. 威胁模型与剩余风险

HACF 的威胁模型包括以下攻击者与失效模式。

• 恶意或被攻陷的 Agent：通过提示注入、工具投毒、上下文污染或模型后门，提出看似合理但有害的动作。HACF 的缓解是独立渲染、动作哈希绑定、契约范围和执行前校验；剩余风险是渲染器或规范化实现漏洞。
• 恶意审批者：滥用权限批准高风险动作，或与请求者合谋。HACF 的缓解是职责分离、双人复核、账本和异常检测；剩余风险是多人合谋和内部权威压力。
• 外部攻击者：伪造审批令牌、篡改账本、窃取签名密钥。HACF 的缓解是签名、哈希链、密钥管理和检查点；剩余风险是密钥泄露和供应链攻击。
• 配置错误：策略过于宽松、阈值设置不当、契约模板遗漏关键约束。HACF 的缓解是策略版本化、审计和红队测试；剩余风险是治理失误。
• 数据泄露：审批界面或账本暴露敏感数据。HACF 的缓解是数据最小化、内容承诺、访问控制和保留期限；剩余风险是侧信道和合法但不当的内部访问。
• 模型漂移：风险分类器随业务变化失效。HACF 的缓解是持续校准、漂移监控和保守回退；剩余风险是缓慢漂移未被及时发现。

E. 评估清单

为保证实验可复现，建议在论文或技术报告中报告以下信息。

1. 任务与环境：任务来源、领域分布、风险等级、时间跨度、环境版本、工具清单、沙箱隔离方式。
2. 风险标注：标注者数量、标注指南、一致性指标、分歧解决机制、风险标签定义。
3. 基线与消融：每个系统的完整配置、模型版本、提示模板、工具权限、阈值和随机种子。
4. 指标：TSR、SHR、UIR、提示次数、人工分钟数、AP、AR、TTR、审计完整性、回滚成功率、成本；每项指标的定义、计算方式和置信区间。
5. 人类研究：样本量、招募标准、被试内/被试间设计、条件平衡、任务顺序、伦理审批、知情同意、脱敏方法。
6. 统计分析：预注册假设、主要/次要终点、混合效应模型设定、多重比较校正、效应量、缺失数据处理。
7. 安全与伦理：红队测试、事故响应、数据保留、员工申诉机制、对审批者绩效数据的使用限制。
8. 可复现性：代码仓库、数据访问方式、环境构建脚本、随机种子、计算资源。

F. 标准映射的说明

表 9 的映射是初步的，目的是说明 HACF 制品如何支持治理活动，而不是声称 HACF 满足某一标准的所有要求。实际合规需要：识别适用条款；评估系统是否属于高风险类别；建立组织治理结构；完成风险评估、技术文档、日志记录、人类监督、准确性和鲁棒性测试；建立上市后监控和事件报告机制。HACF 的契约、账本、门控和反馈学习可以为此提供部分工程证据，但不能替代法律判断、独立审计和监管沟通。

G. 合成压力测试的设计建议

在真实实验之前，可以使用合成环境进行压力测试，但必须明确区分“合成结果”和“实证结果”。合成环境应至少模拟：动作风险分布、可逆性类别、人类审批时间与错误率、审批队列长度、攻击者的提示注入策略、账本写入失败和工具故障。压力测试的目标不是证明 HACF 有效，而是发现设计漏洞，例如：高风险动作是否会被路由到低监督模式；审批令牌是否可能被重放；账本失败时是否真的失败关闭；范围化批准是否会被滥用。合成结果应报告模拟参数、随机种子和敏感性分析，不得作为真实企业效果的证据。

---

写作说明（不属于论文正文）：本文中的实验数值均为占位符，未进行真实企业部署或人类研究；参考文献均来自 arXiv 或公开标准，未编造作者、DOI 或页码。若需将本文推进为可投稿版本，应优先完成第 4 节实验、附录 E 的评估清单和伦理审批，并把所有 [todo: ...] 替换为可核验的数据与配置。