agency-agents：智能体权责契约范式的工程实践-平芜编程栈

1. “agency-agents”不是新词，而是智能体范式演进的临界信号

最近在多个技术社区和开源项目讨论区里，“agency-agents”这个组合词高频出现，既不带空格也不加连字符，像一个被刻意黏合的术语单元。它没有出现在任何权威词典或标准技术文档中，却频繁出现在GitHub仓库名、论文附录的术语表、某高校实验室的内部白板笔记，以及几位资深系统架构师的深夜技术分享录音里。我第一次注意到它，是在调试一个跨服务协调失败的模拟项目X时——日志里反复打印出agent_state: agency_mode=active，而对应模块的包名正是agency-agents。当时以为是拼写错误，直到翻到其README.md第二行写着：“This is not an agent framework. This is anagencyframework — agents here do not execute; theyauthorize,delegate, andattest.”

这个词的核心张力，正在于“agency”（能动性、代理权、自主裁量权）与“agents”（执行体、动作单元、工具化节点）的并置。它拒绝将智能体简化为“能做事的程序”，而是把焦点转向“谁有权决定做什么、由谁做、在什么条件下做、对结果承担何种责任”。这背后是一整套正在成型的协作契约模型：不是A调用B，而是A向B发起一项可验证的委托请求；不是B返回结果，而是B提交一份带签名的履约证明；不是系统记录日志，而是所有参与方共同签署一份不可篡改的协作事实存证。

它解决的不是“怎么让AI更聪明”的问题，而是“当多个异构智能体必须共处一系统、彼此不信任、目标不完全一致、资源受各自策略约束时，如何建立最小可行协作基础”的问题。适合正在设计多智能体协同系统、需要对接第三方服务型Agent、或面临合规审计压力的系统工程师；也适合那些已跑通单点Agent Demo，却在联调阶段反复遭遇“对方Agent擅自修改输入参数”“超时未响应却无凭证追责”“结果可信度无法向下游验证”的团队。这不是语法糖，也不是营销话术，它是把“责任”二字，第一次真正编译进了智能体通信协议的字节码里。

2. 剥离幻觉：从“能干活的Agent”到“有权限的Agency”不是功能升级，而是范式迁移

很多人初看“agency-agents”，下意识把它理解为“更高级的Agent”——比如加了记忆、强化了推理、支持多模态输入。这是最危险的误读。真正的分水岭，不在能力层，而在权责契约层。我们可以用一个生活化类比来说明：传统Agent像一位全权委托的家政阿姨，你告诉她“把客厅打扫干净”，她就去干，你默认她知道怎么干、会干好、干完就算数；而agency-agent则像一位持证上岗的物业管家，你提交的是一份《清洁服务委托单》（含验收标准、时间窗、安全条款），她接单后需先确认权限（是否允许使用蒸汽机？是否可移动花瓶？），执行中每步操作生成带时间戳和数字签名的操作凭证，完工后交付的不是“干净的客厅”，而是一份《服务履约报告》（含清洁前后对比图、设备运行日志哈希、第三方传感器温湿度校验值）。你验收的不是结果本身，而是这份报告能否通过你预设的验证规则集。

这种差异直接映射到代码结构上。传统Agent框架（如LangChain的AgentExecutor）的核心是run()方法：接收输入→调用工具→解析输出→返回结果。而agency-agent框架的核心接口是propose()、authorize()、attest()三元组：

propose(request: Request) -> Proposal：不执行，只生成一份结构化提案，明确列出拟调用工具、预期输入/输出Schema、资源消耗预估、失败回滚路径；
authorize(proposal: Proposal, policy: Policy) -> Authorization：由独立策略引擎（Policy Engine）审核提案是否符合组织级规则（如“禁止调用金融类API”“GPU内存占用不得超过80%”），返回带签名的授权令牌；
attest(execution: Execution) -> Attestation：执行完成后，不返回原始结果，而是生成一份包含执行上下文、环境快照、关键步骤哈希、签名的履约证明。

提示：我在某跨平台系统集成中曾因忽略这一区别栽过跟头。当时直接将一个成熟Agent封装进agency-agents框架，保留了原有的run()入口。结果在压力测试中，当并发请求数超过阈值时，系统不是报“资源不足”，而是持续卡在authorize()环节——因为原Agent的run()隐式消耗了大量未声明的内存，策略引擎检测到实际内存占用远超提案预估，自动拒绝后续授权。修复方案不是优化Agent代码，而是重写其propose()逻辑，强制要求它在执行前完成一次轻量级资源探针。

这种范式迁移带来的根本性变化，是系统可观测性与可审计性的质变。传统Agent的日志是“发生了什么”（what happened），agency-agent的存证是“谁在什么条件下承诺了什么，并如何证明其履行”（who committed to what, under which conditions, and how proven）。这对金融、医疗、工业控制等强合规场景，意味着审计成本可从人工逐条核对日志，降为自动化验证签名链与策略规则的一次性计算。

3. 架构解剖：agency-agents框架的四大支柱与不可妥协的设计约束

一个真正可用的agency-agents框架，绝非在现有Agent库上打补丁。它必须从底层重构四个相互咬合的支柱，每个支柱都承载着对“agency”本质的工程实现。我基于参与的三个模拟项目X的实践，将其拆解为以下核心组件，并标注每项设计背后的硬性约束逻辑。

3.1 权责分离的三层状态机：Proposal → Authorization → Execution

这是整个框架的骨架，其状态流转严格遵循线性不可逆原则。任何试图绕过propose()直接执行，或跳过authorize()伪造授权的行为，在框架启动时即被编译期拦截。具体实现上，我们采用Rust的trait object + lifetime约束来保证：

// 所有Proposal必须实现此trait，且生命周期绑定至创建它的Agency实例 pub trait Proposal: 'static + Send + Sync { fn tool_name(&self) -> &str; fn input_schema(&self) -> Schema; fn resource_estimate(&self) -> ResourceEstimate; } // Authorization必须由PolicyEngine签发，且携带对Proposal的强引用哈希 pub struct Authorization { pub proposal_hash: [u8; 32], // SHA256(proposal_bytes) pub signature: Vec<u8>, pub policy_version: u64, } // Execution只能由持有有效Authorization的Executor触发 pub struct Executor<'a> { auth: &'a Authorization, }

这种设计杜绝了“事后补授权”的灰色地带。我在某图像处理Demo中曾尝试让Executor在执行失败时自动回退到propose()重新生成方案，结果编译器直接报错：Executor does not own Proposal, cannot reconstruct it from hash alone。这看似严苛，实则是保障权责链条完整性的必要代价——Proposal是意图的唯一源头，不可再生。

3.2 策略即代码（Policy-as-Code）引擎：用声明式规则替代硬编码判断

agency-agents的“agency”灵魂，不在Agent自身，而在独立运行的Policy Engine。它不处理业务逻辑，只做一件事：对Proposal进行布尔判定。但这个判定过程必须满足三个刚性要求：可版本化、可回溯、可沙盒验证。

我们采用WasmEdge作为策略执行沙盒，所有策略以WASM字节码形式加载。策略文件policy_v1.2.wasm内容如下（伪代码）：

// 规则1：金融类API调用需双因子认证 if proposal.tool_name == "bank_transfer" { require(proposal.has_mfa_token); } // 规则2：GPU内存占用超75%时拒绝 if proposal.resource_estimate.gpu_mem_mb > 0.75 * system_gpu_total { reject("GPU overcommit risk"); } // 规则3：所有HTTP调用必须启用TLS 1.3+ if proposal.tool_name.starts_with("http_") { require(proposal.tls_version == "1.3"); }

关键创新在于，每次authorize()调用，Policy Engine不仅返回true/false，还同步生成一份PolicyTrace：包含匹配的规则ID、输入参数快照、执行路径哈希。这份Trace与Authorization签名绑定，成为后续审计的黄金数据源。当某次服务异常时，运维人员无需翻查千行日志，只需提取该次请求的Authorization，用相同版本的WASM策略文件重放PolicyTrace，即可100%复现当时的决策依据。

3.3 履约证明（Attestation）生成器：将执行过程转化为可验证证据

这是区别于传统日志的最核心技术点。Attestation不是日志摘要，而是执行过程的密码学封印。它必须包含三类不可伪造的数据：

环境指纹：执行时的系统熵值、CPU微码版本、TPM芯片PCR寄存器值（若可用）；
过程锚点：关键步骤的输入/输出哈希（如调用工具前的参数哈希、返回结果的SHA256）、内存页保护状态快照；
时间证明：由可信时间源（如NTP Pool的证书链）背书的时间戳，而非本地系统时钟。

我们使用Intel SGX的远程证明（Remote Attestation）作为硬件级信任根。Executor在执行前，先向SGX enclave请求一个Quote，其中包含enclave内执行代码的MRENCLAVE哈希（确保代码未被篡改）和当前环境状态。这份Quote与执行过程中的软件锚点一起，构成最终Attestation的主体。下游系统验证时，只需用Intel提供的公钥验证Quote真伪，再用约定算法校验锚点哈希一致性，即可确信该执行过程在指定环境中按预期发生。

注意：在无SGX的开发环境，我们提供纯软件模拟模式（Software Attestation），但会在Attestation中明确标记mode: "simulation"，且所有依赖硬件熵的字段置为零。这确保了测试与生产环境的差异绝对透明，避免“测试通过，上线崩溃”的经典陷阱。

3.4 协作事实总线（Collaboration Fact Bus）：去中心化的存证分发网络

agency-agents的终极价值，在于让多方能就同一事件达成共识。因此，框架内置一个轻量级事实总线，其设计哲学是“最小化中心化依赖”。它不存储原始数据，只广播结构化存证事件：

{ "event_type": "AttestationPublished", "attestation_id": "sha256:abc123...", "signer_id": "agent-xyz@domain.com", "witnesses": ["policy-engine-v1.2", "time-oracle-ntp.org"], "proof": "base64_encoded_signature_chain" }

所有参与者（Agent、Policy Engine、审计系统）均可订阅此总线。当某Agent发布Attestation，总线不验证其真伪，只确保消息有序、不丢失。验证工作由各订阅者自行完成——Policy Engine验证签名链，时间服务验证时间戳，审计系统则聚合多方见证。这种设计使系统具备天然抗单点故障能力：即使总线短暂中断，只要各节点缓存了待验证事件，恢复后仍能完成最终一致性校验。

4. 实战推演：在模拟项目X中落地agency-agents的七步通关路径

理论终须落地。我以某高校实验室的模拟项目X（一个需协调无人机群、地面机器人、气象传感器三方协作的灾害响应仿真系统）为例，完整复现从零开始集成agency-agents框架的实操路径。每一步都标注了真实踩过的坑和对应解法，绝非理想化流程。

4.1 步骤一：识别“agency敏感点”——不是所有Agent都需要改造

项目X原有代码库包含12个Agent模块。盲目改造全部是灾难。我们采用“影响域分析法”快速定位核心改造对象：

Agent模块	是否需改造	判断依据	改造优先级
DroneFlightController	是	直接操控物理设备，涉及安全边界与实时性约束	P0（最高）
WeatherDataFetcher	是	调用外部API，结果可信度影响下游决策	P0
ReportGenerator	否	纯数据聚合，无外部依赖与权限争议	P3（暂缓）
MapRenderer	否	本地计算，结果不参与协作决策	P3

关键洞察：只有当Agent的行为可能引发跨域权责争议时，才需升格为agency-agent。例如，DroneFlightController若擅自更改飞行高度规避障碍，需明确其是否有此权限；WeatherDataFetcher若缓存旧数据导致误判，需证明其获取的是最新API响应。而ReportGenerator只是把别人给的数据画成图，权责清晰，无需复杂契约。

4.2 步骤二：定义领域专属Proposal Schema——用结构化语言约束意图表达

针对P0级Agent，我们首先设计其Proposal Schema。以DroneFlightController为例，其propose()方法必须返回的JSON Schema如下（精简版）：

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "required": ["mission_id", "target_altitude", "max_deviation", "emergency_protocol"], "properties": { "mission_id": {"type": "string"}, "target_altitude": {"type": "number", "minimum": 30, "maximum": 120}, "max_deviation": {"type": "number", "minimum": 0.5, "maximum": 5.0}, "emergency_protocol": {"enum": ["return_to_base", "hover_in_place", "land_immediately"]} } }

这个Schema的威力在于：它不仅是数据格式规范，更是权限谈判的语言。Policy Engine的规则可直接引用Schema字段，如require(proposal.target_altitude <= 100)。更重要的是，它迫使开发者在编码初期就思考“我的Agent究竟要承诺什么”，而非等到出问题时再争论“当时是不是想飞那么高”。

踩坑实录：最初版本遗漏了emergency_protocol字段，导致Policy Engine无法审核紧急情况下的行为。当模拟突发强风时，DroneFlightController自行触发land_immediately，但因无事前授权，其Attestation被审计系统标记为“越权操作”。修复方案不是放宽策略，而是强制在Schema中明确定义所有可能的应急分支，并在propose()中要求开发者显式选择。

4.3 步骤三：编写Policy Engine策略——从模糊规则到可执行代码

基于Schema，我们编写第一条策略drone_safety_v1.wasm：

;; 规则：飞行高度不得高于100米，且必须有应急协议 (func $validate_proposal (param $proposal_ptr i32) (result i32) local.get $proposal_ptr call $get_target_altitude f64.const 100.0 f64.le if (result i32) local.get $proposal_ptr call $has_emergency_protocol else i32.const 0 end)

关键技巧：策略代码必须无副作用、无外部I/O、纯函数式。所有依赖（如当前天气数据）必须作为Proposal的一部分传入，而非在策略中实时查询。这保证了策略执行的确定性与可重现性。我们在测试时发现，某次策略因调用了get_system_time()导致每次执行结果不同，立即被框架拒绝加载——这是设计上的主动防御。

4.4 步骤四：改造Executor——注入Attestation生成逻辑

原DroneFlightController的execute()方法仅返回Result<FlightStatus>。改造后，其核心逻辑被包裹在attest_execution()闭包中：

def attest_execution(self, proposal: Proposal, auth: Authorization) -> Attestation: # 1. 记录执行前环境指纹 pre_env = self.capture_environment() # 2. 执行原业务逻辑 result = self._original_execute(proposal) # 3. 记录执行后状态与关键锚点 post_env = self.capture_environment() anchor_hash = hashlib.sha256( json.dumps({ "input": proposal.dict(), "output": result.dict(), "pre_env_hash": pre_env.hash, "post_env_hash": post_env.hash }).encode() ).hexdigest() # 4. 生成Attestation（含SGX Quote） quote = self.sgx_quote(anchor_hash) return Attestation( proposal_id=proposal.id, auth_id=auth.id, anchor_hash=anchor_hash, quote=quote, timestamp=self.trusted_time() )

这里的关键经验：Attestation的锚点（anchor）必须包含输入与输出的完整哈希，而非仅输出。否则，攻击者可能重放同一输出到不同输入，伪造履约。我们在渗透测试中故意将anchor_hash计算简化为hash(output)，结果被轻易攻破——这印证了“输入即契约”的设计哲学。

4.5 步骤五：部署协作事实总线——用轻量级MQTT实现事件广播

我们选用Mosquitto MQTT Broker作为事实总线，主题设计遵循agency/{domain}/{agent_type}/{event}层级：

agency/disaster/drone/AttestationPublished
agency/disaster/weather/PolicyDecision
agency/disaster/audit/VerificationResult

所有Agent发布Attestation时，仅向对应主题推送事件，不关心谁订阅。审计系统作为独立服务，订阅所有AttestationPublished主题，收到事件后：

下载对应Attestation详情；
验证签名链与SGX Quote；
校验锚点哈希；
将验证结果（valid/invalid/inconclusive）发布到agency/disaster/audit/VerificationResult主题。

这种松耦合设计，让审计系统可随时启停，不影响主业务流。某次审计服务意外崩溃，总线持续广播事件，待其恢复后，自动消费积压消息完成补验，全程零人工干预。

4.6 步骤六：构建端到端验证流水线——让“信任”可自动化

为确保整个链条可靠，我们搭建CI/CD验证流水线，每次代码提交必跑：

Proposal生成测试：用随机数据生成1000个Proposal，验证其100%符合Schema；
Policy覆盖率测试：用模糊测试工具生成Proposal变体，确保策略代码分支覆盖率达100%；
Attestation完整性测试：在SGX模拟器中执行，验证生成的Attestation能被独立验证器成功校验；
总线事件一致性测试：模拟网络分区，验证事件最终能被所有订阅者正确接收与处理。

这条流水线成为团队的“信任基石”。当某次策略更新后，流水线第2步失败，提示“规则emergency_protocol未被任何测试用例触发”，我们立刻意识到新规则存在逻辑盲区，及时补充测试用例，避免了线上隐患。

4.7 步骤七：灰度发布与渐进式验证——用数据驱动信任建立

最后一步，绝不全量切换。我们采用“双轨制”灰度：

流量镜像：将10%的真实请求，同时发送给旧Agent和新agency-agent，比对两者输出与耗时；
决策仲裁：当两者结果不一致时，交由人工仲裁员（领域专家）裁定，并记录为训练数据；
信任积分：为每个agency-agent维护一个trust_score，初始为0.1，每次成功通过审计验证+0.01，每次仲裁裁定为错误-0.05。当trust_score > 0.8时，才允许其处理P0级任务。

三个月后，DroneFlightController的trust_score稳定在0.92，WeatherDataFetcher达0.87，我们才将其提升为生产主力。这个过程不是技术炫技，而是用可量化的数据，让团队真正建立起对“agency”范式的信心。

5. 边界与清醒：agency-agents不是银弹，它的适用性光谱与现实约束

尽管agency-agents代表了智能体协作的前沿方向，但必须清醒认识其适用边界。它不是万能解药，强行套用反而会增加不必要的复杂度。根据我们在模拟项目X及另外两个工业场景中的实践，总结出其适用性光谱与三条不可逾越的现实约束。

5.1 适用性光谱：从“强需求”到“不推荐”的四象限判断

我们用两个维度评估一个场景是否适合引入agency-agents：权责争议强度（横轴）与协作方信任基线（纵轴），划分为四象限：

低信任基线（多方互不信任）	高信任基线（同团队/同组织）
高权责争议（安全、合规、财务）	✅ 强烈推荐：如无人机集群调度、跨机构医疗数据共享、金融交易路由	⚠️ 可选：若已有成熟内部审计流程，可暂缓，但长期建议
低权责争议（内部工具、实验性原型）	❌ 不推荐：过度设计，开发效率暴跌	❌ 不推荐：纯属增加负担，传统Agent更敏捷

典型强需求场景包括：

多租户SaaS平台：不同客户的数据处理Agent必须严格隔离，且操作需留痕供客户审计；
边缘计算集群：由不同厂商设备组成的物联网网络，需统一验证各设备Agent的固件更新与数据上报行为；
AI模型服务市场：第三方模型提供者发布的Agent，需向调用方证明其未篡改输入、未泄露数据、按约定精度执行。

而典型的不推荐场景是：

个人开发者做的单机AI助手，所有Agent都在自己电脑上运行；
快速验证想法的Hackathon项目，核心目标是两周内做出Demo；
已有稳定运行五年、无权责纠纷历史的内部脚本系统。

5.2 约束一：性能开销是硬币的另一面——必须接受15%-30%的吞吐量折损

agency-agents的权责契约必然带来性能成本。我们的基准测试显示，在同等硬件上：

操作	传统Agent	agency-agent	折损率
Proposal生成	0.2ms	1.8ms	+800%
Policy Engine审核	0.1ms	0.9ms	+800%
Attestation生成（含SGX）	0.5ms	3.2ms	+540%
端到端延迟（P95）	12ms	15.8ms	+32%

这个折损率并非bug，而是为“可验证性”支付的必要代价。关键在于接受它，并针对性优化。我们的做法是：

对Proposal生成，采用预编译Schema模板，避免运行时JSON Schema解析；
对Policy Engine，将高频规则（如target_altitude检查）编译为机器码，冷门规则（如特殊天气协议）才走WASM解释；
对Attestation，仅对P0级操作生成完整SGX证明，P1级操作使用轻量级软件证明。

经验之谈：曾有团队试图通过取消pre_env采集来降低Attestation开销，结果在一次硬件故障中无法区分是Agent Bug还是CPU微码缺陷导致的异常，被迫回滚。这印证了：性能优化的底线，是不能牺牲关键锚点的完整性。

5.3 约束二：开发者心智模型需重构——从“写功能”到“写契约”

最大的落地阻力，往往来自开发者习惯。传统开发思维是“我要实现什么功能”，而agency-agents要求“我要向谁承诺什么，凭什么让人相信”。这需要三重转变：

接口设计前置：propose()的Schema必须在编码前由架构师、安全官、领域专家共同评审签字，而非写完代码再补文档；
错误处理范式变更：不再有try-catch，所有异常必须转化为ProposalRejection或AttestationInvalid，并附带可审计的拒绝理由；
测试重心转移：单元测试重点不再是“输出是否正确”，而是“Proposal是否完备”、“Policy是否覆盖所有边界”、“Attestation能否被独立验证”。

我们在某次代码审查中发现，一位资深工程师在propose()中写了if weather.is_stormy(): raise Exception("Cannot fly")，这违反了契约精神——异常是内部实现细节，Proposal应体现为emergency_protocol: "return_to_base"的显式声明。我们要求其重构，将气象判断逻辑移入Policy Engine，propose()只负责声明意图。

5.4 约束三：生态成熟度尚在早期——需自建关键组件，勿期待开箱即用

目前并无成熟的“agency-agents”商业框架。主流选择是：

自研核心：基于Rust/Go重写Proposal状态机、Policy Engine沙盒、Attestation生成器；
复用周边：MQTT总线、WasmEdge运行时、SGX SDK、Prometheus监控；
谨慎选型：避免绑定单一硬件（如只支持SGX），预留TPM 2.0、SEV等其他可信执行环境（TEE）的适配接口。

这意味着，采用agency-agents不是选一个SDK，而是启动一个中型基础设施项目。团队需具备系统编程、密码学、硬件安全的基础能力。某公司曾试图用Python快速封装，结果在Attestation生成环节因GIL锁导致吞吐量暴跌，最终不得不重写核心模块。

我自己的体会是：agency-agents的价值，不在于它解决了多少新问题，而在于它迫使我们直面那些长期被掩盖的老问题——权责不清、验证缺失、信任脆弱。当你开始为一个Agent写Proposal Schema时，你已经在思考“我的代码，究竟向世界承诺了什么”。这种思考本身，就是工程成熟度跃迁的起点。