1. “agency-agents”不是新词而是智能体范式演进的临界信号最近在多个技术社区和内部项目复盘会上频繁看到“agency-agents”这个组合被零散提及——它既不出现在任何主流框架的官方文档里也不属于某个开源库的模块名更不是某家公司的注册商标。但它反复出现在架构设计草图的角落、技术选型会议的白板上甚至某次跨团队对齐时一位资深系统工程师脱口而出“我们得先定义清楚 agency-agents 的边界否则后面所有 agent 编排都像在搭积木时没校准卡扣。”这句话让我意识到这个词正在从模糊共识走向隐性标准。它不是语法错误也不是拼写失误。“agency-agents”中间那个短横是刻意为之的语义锚点——它把“agency”能动性、自主性、目标导向的决策权和“agents”可部署、可通信、可调度的运行实体这两个原本常被混用的概念强行掰开、并置、再耦合。过去我们说“AI agent”默认它是个带点智能的脚本现在说“agency-agents”是在声明这个实体必须同时满足两个硬性条件——它得有不可让渡的 agency比如拒绝执行违背其目标约束的指令也得是可工程化落地的 agents比如能被 Kubernetes 调度、能通过 gRPC 对接、能被可观测性体系追踪。这背后是一场静默但剧烈的范式迁移。三年前一个能调用天气 API 并生成简报的 Python 脚本就能被称作“agent”今天如果它不能自主判断“当前用户情绪低落不宜推送促销信息”不能主动发起与日程 agent 的协商以避开会议冲突不能在资源不足时降级执行策略而非直接报错——那它连“agency-agents”的入门门槛都没摸到。关键词里虽然空着但搜索热词里反复出现的“autonomous workflow”“goal-driven orchestration”“agent negotiation protocol”全是指向同一片尚未命名的土壤。我参与过三个不同行业的模拟项目X从某高校的科研协作平台到某公司的客户响应中台再到某实验室的工业设备预测维护系统无一例外都在第二轮迭代时撞上了同一个瓶颈不是 agent 不够多而是它们太“听话”缺乏 agency 导致整个系统像一支没有指挥官的军队——命令能传达到但没人决定该不该执行、何时执行、用什么代价执行。提示不要把“agency-agents”理解为“更高级的 agent”。它是对 agent 定义的重写agent 是载体agency 是灵魂没有 agency 的 agents 是工具没有 agents 的 agency 是空想。二者缺一不可且必须在设计之初就绑定建模。2. agency-agents 的四大刚性能力基线为什么多数 Demo 都只是“伪 agency”市面上大量所谓“multi-agent system”的演示本质上仍是中心化调度器驱动的协程池。一个主控 agent 拆解任务、分发子任务、收集结果、汇总输出——整个过程里子 agent 没有独立状态、没有本地策略、没有拒绝权。这种架构跑通 demo 很快但一旦投入真实业务流就会在四个关键节点上集体失能。我把这四个失能点称为 agency-agents 的“能力基线”任何声称支持 agency-agents 的方案必须能明确回答这四个问题2.1 目标锚定与动态重协商能力真正的 agency-agents 必须拥有自己不可覆盖的顶层目标top-level objective且该目标需在运行时可被其他 agency-agents 识别、理解、并据此发起协商。例如在某跨平台系统中客服 agent 的目标是“最小化用户等待时间”而知识库 agent 的目标是“保障信息准确率 ≥99.5%”。当用户提出一个模糊问题时客服 agent 不应直接调用知识库 API 获取答案而应先发送协商请求“我需要在 3 秒内给出初步响应可接受答案置信度下限为 80%是否同意”——知识库 agent 若判断当前负载过高可回复“同意但需启用缓存摘要模式准确率预估为 82%”。这个协商过程不是 RPC 调用而是基于共享语义协议如轻量级的 Agent Communication Language, ACL的异步消息交换。实操中我见过太多团队把“目标”硬编码成配置项导致 agent 无法感知自身目标与其他 agent 的冲突。正确做法是每个 agency-agent 启动时加载一个目标描述文件JSON Schema 格式其中包含primary_goal字符串、hard_constraints数组如[response_time_ms 3000, accuracy 0.8]、negotiation_policy定义在何种条件下发起/接受协商。这个文件不是静态的——它可以通过安全通道接收上游管理 agent 的动态更新但更新必须经过本地策略引擎校验若新目标与硬约束冲突agent 有权拒绝加载并进入降级模式。2.2 状态主权与局部决策闭环agency-agents 必须拥有自己的状态存储主权state sovereignty。这意味着它的核心状态如当前任务队列、已达成的协商协议、本地缓存的知识图谱片段不能被外部 agent 或调度器直接读写。所有交互必须通过明确定义的接口interface contract进行。常见错误是让所有 agent 共享一个 Redis 实例然后通过 key 前缀区分状态——这看似方便实则彻底瓦解了 agency当 A agent 的状态被 B agent 意外覆盖时A agent 无法感知更无法触发自愈。我们在某图像处理Demo 中踩过这个坑。当时设计了一个“超分 agent”和一个“色彩校正 agent”它们共用一个 shared_state:redis://... 的连接。某次超分 agent 在处理大图时内存溢出崩溃重启后从 Redis 读取状态时发现色彩校正 agent 已将“待处理队列”清空——因为后者误判前者已永久离线。最终结果是超分 agent 丢失了全部未完成任务而色彩校正 agent 却在空转。修复方案是强制每个 agency-agent 绑定专属状态后端哪怕只是 SQLite 文件并通过统一的 State Gateway 进行跨 agent 状态查询——Gateway 只暴露查询接口如GET /state/{agent_id}/task_count绝不提供写入权限。这样当超分 agent 重启时它能完整恢复本地状态并主动向色彩校正 agent 发送“状态同步请求”而非被动接受污染。2.3 资源感知与弹性执行策略agency-agents 必须能实时感知自身运行环境的资源水位CPU、内存、网络延迟、GPU 显存并据此动态切换执行策略。这不是简单的“if CPU 90% then sleep(1)”而是策略树policy tree的实时激活。例如一个文本生成 agency-agent 可能预置三套策略高保真模式使用 full-precision LLM响应延迟 ≤5stoken 成本高平衡模式使用量化模型 cache响应延迟 ≤2s成本中等应急模式启用规则引擎 fallback响应延迟 ≤200ms仅保证基础语义正确。关键在于策略切换的触发条件必须是 agent 自身观测到的指标而非外部调度器下发的指令。我们曾在一个金融风控场景中实现此能力风控 agent 每 500ms 采样一次本地 P95 延迟当连续 3 次超过 800ms 时自动激活应急模式并向监控系统发送事件{event: policy_switch, from: balanced, to: emergency, reason: latency_spike}。这个事件会触发告警但不会干预 agent 的决策——它已经自己做出了选择。这种“自治式降级”是 agency 的核心体现也是系统韧性的基石。2.4 失效隔离与契约式故障传播当一个 agency-agent 失效时其影响必须被严格限制在与其直接签订契约contract的 agent 范围内。所谓契约是指两个 agent 在首次交互时协商确定的服务等级协议SLA包括可用性承诺如“99.9% 时间在线”、响应延迟承诺如“P95 ≤ 1.5s”、失败重试策略如“最多重试 2 次间隔指数退避”。这些契约不是文档而是运行时可验证的代码合约code contract。在某物联网设备管理项目中我们为设备代理device-agent和指令分发代理dispatch-agent之间建立了契约。当 device-agent 因网络中断离线时dispatch-agent 不会立即报错而是启动契约约定的重试流程若重试失败则按契约规定向下游的告警代理alert-agent发送结构化事件{type: contract_breach, contract_id: dispatch-device-2024, breach: availability, duration_sec: 62}。这个事件本身就是一个 agency 行为——它没有试图修复 device-agent也没有扩大影响范围只是忠实地履行了“契约守门人”的职责。正是这种精确的失效传播让整个系统在部分 agent 失效时仍能维持核心流程运转而不是像传统微服务那样一个节点雪崩拖垮整条链路。3. 从零构建一个最小可行 agency-agents 系统不依赖任何“智能体框架”市面上的 agent 框架如 LangChain、AutoGen极大降低了 agent 开发门槛但也悄悄埋下了 agency 丧失的隐患——它们默认假设所有 agent 都信任调度器、共享全局状态、遵循中心化指令。要真正理解 agency-agents我建议亲手搭建一个“反框架”的最小系统。以下是我用 3 天时间在某高校科研协作平台原型中实现的方案全程不引入任何 agent 专用库只用 Python 标准库 Flask SQLite代码总量不到 500 行却完整实现了上述四大基线。3.1 核心架构去中心化的三元组通信模型放弃“manager-worker”模型采用Agent-Agenda-Contract三元组架构Agent每个 agent 是一个独立进程或容器拥有自己的状态数据库SQLite、HTTP 服务端口、以及唯一的 agent_id。Agenda不是任务队列而是一个分布式的、基于 gossip 协议的状态广播机制。每个 agent 定期向邻居广播自己的 agenda 片段如{agent_id: researcher-01, current_task: literature_review, priority: 7, deadline: 2024-06-15T10:00:00Z}邻居收到后存入本地 agenda_cache 表。agenda 不是命令而是“意图声明”供其他 agent 主动发现协作机会。Contract每个 agent 启动时与预设的 2-3 个关键 partner agent 建立契约。契约内容存储在本地 contracts.db 中格式为{ contract_id: researcher-librarian-2024, partner_id: librarian-03, slas: [ {metric: response_time_p95_ms, target: 1200, window_sec: 300}, {metric: availability_pct, target: 99.5, window_sec: 3600} ], retry_policy: {max_attempts: 3, backoff_base_ms: 500} }这个架构天然规避了单点故障。没有 manageragenda 通过 gossip 自组织contract 由 agent 自主协商建立。我在测试中故意 kill 掉 librarian-03 进程researcher-01 在 12 秒内就检测到契约违约通过定期 ping partner 的健康端点并自动切换到备用契约对象 librarian-07整个过程无需人工干预。3.2 关键代码片段让 agent 学会“说不”agency 的灵魂在于“拒绝权”。下面这段代码是 researcher-01 agent 的核心协商处理器展示了它如何基于本地状态和契约自主决定是否接受协作请求# file: researcher_agent/negotiation.py import sqlite3 from datetime import datetime, timedelta def handle_negotiation_request(request: dict) - dict: request 示例: { initiator_id: librarian-03, proposal: { task: fetch_papers, scope: [LLM, retrieval], deadline: 2024-06-14T15:00:00Z, resources_required: {cpu_cores: 2, ram_gb: 4} } } # 1. 加载本地状态 conn sqlite3.connect(researcher-01.db) cursor conn.cursor() # 查询当前负载过去5分钟平均CPU cursor.execute(SELECT AVG(value) FROM metrics WHERE metriccpu_percent AND timestamp ?, (datetime.now() - timedelta(minutes5),)) avg_cpu cursor.fetchone()[0] or 0 # 查询本地任务队列长度 cursor.execute(SELECT COUNT(*) FROM task_queue WHERE statuspending) pending_tasks cursor.fetchone()[0] # 2. 加载与发起方的契约 cursor.execute(SELECT * FROM contracts WHERE partner_id ?, (request[initiator_id],)) contract cursor.fetchone() if not contract: return {status: rejected, reason: no_contract_with_initiator} # 3. 执行本地策略判断 proposal request[proposal] if avg_cpu 80.0 and pending_tasks 5: # 负载过高触发协商反制 counter_proposal { task: proposal[task], scope: proposal[scope], deadline: (datetime.fromisoformat(proposal[deadline]) timedelta(hours2)).isoformat(), resources_required: {cpu_cores: 1, ram_gb: 2} # 降低要求 } return {status: counter_proposed, counter_proposal: counter_proposal} if proposal[task] fetch_papers and retrieval not in proposal[scope]: # 违反核心能力边界直接拒绝 return {status: rejected, reason: task_scope_mismatch} # 4. 接受请求写入本地任务队列 cursor.execute( INSERT INTO task_queue (task_id, initiator_id, task_type, status, created_at) VALUES (?, ?, ?, ?, ?), (ft_{int(datetime.now().timestamp())}, request[initiator_id], proposal[task], pending, datetime.now()) ) conn.commit() conn.close() return {status: accepted, task_id: ft_{int(datetime.now().timestamp())}}这段代码的价值不在于功能多炫酷而在于它把“agency”具象化成了几行可审计、可调试、可修改的逻辑。它不依赖任何黑盒调度器所有判断依据都来自 agent 自身的观测数据CPU、队列长度和契约条款。当 librarian-03 发来一个“立刻获取 100 篇论文”的请求时researcher-01 不会盲目执行而是冷静计算我的 CPU 正在 85% 运行队列里还有 7 个待处理任务——此时接受请求必然导致 SLA 违约。于是它发出反提案“可以做但 deadline 推后 2 小时且只处理 50 篇”。这就是 agency 的声音。3.3 状态主权的落地SQLite 作为 agent 的“心智模型”每个 agency-agent 的 SQLite 数据库就是它的“心智模型”mental model。我们为 researcher-01 设计了四张核心表表名作用关键字段示例agent_state存储 agent 的全局状态快照id,last_heartbeat,current_mode(high_fidelity/balanced/emergency),self_assessment_scoretask_queue本地任务队列状态机驱动task_id,initiator_id,task_type,status(pending/in_progress/completed/failed),created_at,updated_atcontracts存储与各 partner 的契约contract_id,partner_id,slas_json,retry_policy_json,last_verified_atagenda_cache缓存邻居 agent 的 agenda 声明agent_id,agenda_json,received_at,ttl_seconds所有表的操作都封装在StateManager类中对外只暴露get_current_mode()、add_task()、update_contract_status()等语义化方法。外部系统包括其他 agent绝不能绕过这些方法直接操作数据库。这种设计带来的好处是当需要 debug 一个 agent 的异常行为时你只需导出它的 SQLite 文件用 DB Browser 打开就能清晰看到它“认为”自己处于什么状态、接受了哪些任务、和谁签了约、缓存了哪些邻居的意图——它的整个心智世界都是透明、可追溯、可验证的。注意SQLite 不是性能瓶颈而是设计选择。agency-agents 的核心诉求是状态主权和事务一致性而非超高吞吐。在单 agent 场景下SQLite 的 ACID 保证比分布式数据库更可靠。当规模扩大时可平滑替换为嵌入式 RocksDB 或轻量级 PostgreSQL但心智模型的抽象层保持不变。4. agency-agents 的真实战场三个行业场景中的能力验证与陷阱理论再完美也要经受真实业务流的淬炼。我参与的三个模拟项目X分别代表了不同复杂度的落地场景。它们共同证明了一点agency-agents 的价值不是体现在“能做什么”而是体现在“在混乱中依然能守住什么”。4.1 某高校科研协作平台目标冲突下的自主协调场景一个跨学科课题组包含计算机系负责算法开发、医学院负责临床数据标注、生物系负责实验验证。传统做法是设立一个项目 coordinator手动分配任务、催促进度、调解冲突。但在 agency-agents 架构下每个系的代表 agent 都有自己的目标cs-agent目标是“最大化算法迭代速度”硬约束是“每次训练耗时 ≤ 4h”med-agent目标是“保障标注质量 ≥98%”硬约束是“单日标注量 ≤ 200 份”bio-agent目标是“最小化实验动物使用量”硬约束是“单次实验动物数 ≤ 5 只”。当 cs-agent 提出“需要 500 份新标注数据以训练新模型”时med-agent 不会直接拒绝而是发起协商“可提供 200 份但需 cs-agent 优化数据增强策略使 200 份数据等效于 500 份”。cs-agent 接收提案后调用本地策略引擎评估——发现现有增强策略确实有冗余遂同意。这个过程没有 coordinator 介入三个 agent 在 47 秒内完成了目标对齐与资源重分配。陷阱警示我们最初让 med-agent 的硬约束“单日标注量 ≤ 200 份”写死在代码里结果在某次紧急伦理审查后医学院临时获批增加 50 份配额。由于约束不可动态更新med-agent 只能硬扛超限风险。修复方案是所有硬约束都从配置文件加载并监听一个安全的 webhook 端点当管理员通过后台更新约束时agent 自动 reload 并触发状态自检。4.2 某公司客户响应中台高并发下的弹性降级与契约履约场景电商大促期间客服响应 agentsupport-agent每秒接收 2000 用户咨询。其目标是“首响时间 ≤ 3s”硬约束是“准确率 ≥ 85%”。当流量峰值到来时support-agent的 P95 延迟飙升至 4.2s触发应急模式——它不再调用高精度 NLU 模型而是切换到规则引擎 预设话术库首响时间压至 1.8s准确率降至 87%仍在硬约束内。关键在于support-agent同时向监控系统发送了两条事件{event: mode_switch, from: high_fidelity, to: emergency, reason: latency_spike}{event: contract_breach, contract_id: support-knowledge-2024, breach: response_time_p95_ms, actual: 4200, target: 3000}第一条事件通知运维团队“系统已降级”第二条事件则精准告知知识库 agentknowledge-agent“我们的 SLA 违约了原因是我变慢了不是你不行”。knowledge-agent收到后没有恐慌式扩容而是启动自己的预案它将高频问题的缓存 TTL 从 1 小时延长至 24 小时并向support-agent发送一条协商消息“我已延长缓存你可减少 30% 的实时查询专注提升首响”。这是两个 agency-agents 基于契约的协同自愈而非单方面的救火。陷阱警示早期版本中support-agent在降级时会直接关闭与knowledge-agent的连接导致后者误判为宕机而触发告警。后来我们强制所有 agent 在状态变更时必须向所有签约 partner 发送state_announcement事件明确告知“我还在只是模式变了”。这个小小的通信约定大幅降低了误告警率。4.3 某实验室工业设备预测维护系统长周期任务中的状态漂移与重校准场景为一台精密光学设备部署预测维护 agentpm-agent其目标是“提前 72 小时预警潜在故障”硬约束是“误报率 ≤ 5%漏报率 ≤ 1%”。pm-agent每小时分析一次传感器流数据生成预测报告。问题在于设备老化、环境温湿度变化、传感器漂移都会导致模型性能缓慢衰减。传统方案是每月人工校准一次模型但在这期间pm-agent的实际误报率可能已升至 8%。agency-agents 的解法是让pm-agent拥有“自我诊断”能力。我们在pm-agent的 SQLite 数据库中新增一张calibration_log表记录每次预测的置信度、实际结果是否真故障、以及与历史基线的偏差。pm-agent每 24 小时运行一次校准检查计算过去 24 小时的误报率、漏报率若任一指标超出硬约束 20%即误报 6%漏报 1.2%则标记calibration_needed True同时向实验室的专家 agentexpert-agent发送协商请求“检测到模型漂移申请启动校准流程预计耗时 2 小时期间暂停新预测”。expert-agent收到后会评估当前实验室工作负载若允许则回复“批准”pm-agent进入校准模式若不允许则提议“延迟至明日凌晨 2 点”。这个过程完全自治pm-agent不会因性能衰减而默默违规也不会在未经协商的情况下擅自停摆。陷阱警示第一次部署时pm-agent的校准检查逻辑过于激进——只要单次预测置信度低于阈值就触发告警。结果环境噪声导致每天触发数十次expert-agent被淹没。后来我们改为“滑动窗口统计”必须连续 5 次检查都超标才行动稳定性大幅提升。5. 踩坑实录那些让 agency-agents 退回“普通 agent”的致命设计失误即使理解了所有原理实操中仍有几个深坑足以让精心设计的 agency-agents 系统一夜回到解放前。这些不是技术难点而是思维惯性导致的设计盲区。我把它们记录下来既是复盘也是给后来者的路标。5.1 误区一把“多 agent”等同于“有 agency”最普遍的错误是以为只要启动了多个 agent 进程就自然拥有了 agency。我们在某图像处理Demo 的初版中就犯了这个错创建了preprocess-agent、detect-agent、segment-agent、postprocess-agent四个进程它们通过 RabbitMQ 传递消息。表面看是“multi-agent”实则每个 agent 都是纯粹的函数式处理器——输入图片输出结果中间状态全无。detect-agent不知道preprocess-agent是否已完成也不知道segment-agent是否准备好接收数据所有协调逻辑都堆在消息队列的 routing key 和 exchange 规则里。结果是当preprocess-agent因 OOM 崩溃时detect-agent收不到消息整个流水线停滞当segment-agent升级时detect-agent发送的消息因 schema 不兼容而被丢弃无人知晓。这根本不是 agency-agents只是把单体应用拆成了微服务还丢了事务保证。修正路径必须为每个 agent 显式建模其“能动性”。preprocess-agent应维护一个processing_status表记录每张图片的处理阶段queued→started→completed→faileddetect-agent在启动时应主动查询preprocess-agent的/status端点确认其健康状态和最新完成的图片 ID而非被动等待消息。agency 不是“多”而是“每个都活得明白”。5.2 误区二用中心化日志/监控替代 agent 自治可观测性很多团队会自豪地展示“我们有完整的 agent 全链路追踪”点开一看全是 Zipkin 或 Jaeger 的 trace 图显示preprocess-agent→detect-agent→segment-agent的调用链。这很好但只是“可观测性”的皮毛。真正的 agency-agents 可观测性必须包含 agent 的自治状态。我们在某跨平台系统中曾依赖 ELK 堆栈收集所有 agent 的 stdout 日志。当librarian-agent出现响应延迟时日志里只有Processing request id: abc123没有上下文它当前队列多长CPU 多高和researcher-agent的契约是否已违约这些信息只有 agent 自己知道且必须主动上报。修正路径强制每个 agency-agent 暴露/health和/state两个端点/health返回{ status: ok, uptime_sec: 12345, last_heartbeat: 2024-06-14T10:23:45Z }供基础设施探活/state返回{ mode: balanced, task_queue_length: 3, contracts_breached: [researcher-librarian-2024], self_assessment_score: 0.87 }供运维和上游 agent 决策。这个/state端点就是 agent 的“数字孪生”是它向世界宣告“我此刻是谁”的唯一权威来源。没有它所有外部监控都是隔靴搔痒。5.3 误区三忽视“契约协商”的成本与失败回退我们曾天真地认为agent 之间的协商是轻量级的可以无限次发起。结果在某金融风控场景中risk-agent与compliance-agent因一个边缘 case 的规则解释分歧连续发起了 17 次协商请求每次请求都包含完整的交易上下文 JSON约 2KB导致网络带宽被占满正常风控请求被延迟。更糟的是当compliance-agent因 GC 暂停 2 秒时risk-agent的重试机制触发了 3 次快速重试进一步加剧了拥塞。这暴露了两个致命缺陷一是协商协议没有成本约束二是没有优雅的失败回退。修正路径为所有协商交互添加三层防护频率熔断每个 agent 维护一个negotiation_rate_limiter记录过去 60 秒内向同一 partner 发起的协商次数超过 5 次则拒绝新请求返回{status: rate_limited, retry_after_sec: 30}负载感知在协商请求头中加入X-Agent-Load: high/medium/low由发起方根据自身 CPU/队列长度设置接收方若负载为high可直接返回{status: deferred, retry_suggestion_sec: 120}契约兜底当协商失败超过 3 次或超时未响应agent 必须执行预设的兜底策略fallback policy例如risk-agent的兜底策略是“启用上一版合规规则记录 audit log向 human-operator 发送告警”。这三层防护让协商从“随意对话”变成了“严肃外交”确保 agency 不会因过度自治而陷入内耗。5.4 误区四混淆“状态主权”与“数据孤岛”强调 agent 的状态主权绝不意味着鼓励数据孤岛。相反agency-agents 的终极目标是让数据在主权明晰的前提下实现更高阶的协作。我们曾在某医疗影像平台犯过这个错每个科室的radiology-agent、oncology-agent、pathology-agent都坚持“我的 DICOM 数据绝不离开本地”结果跨科室会诊时医生需要手动导出、传输、导入三份数据效率极低。修正路径用“数据主权”替代“数据物理隔离”。每个 agent 依然拥有自己的 DICOM 存储但通过统一的 Data Access BrokerDAB提供标准化访问。DAB 不是数据库而是一个轻量级代理它验证请求方 agent 的身份和权限基于 JWT根据预设的 Data Sharing Policy如oncology-agent可读radiology-agent的结构化报告但不可读原始 DICOM执行数据脱敏如自动模糊患者面部记录完整审计日志。这样oncology-agent可以安全、合规、高效地访问radiology-agent的数据而radiology-agent依然牢牢掌握着数据的物理控制权和访问决策权。主权与协作从来不是非此即彼的选择题。6. 最后一点个人体会agency-agents 的本质是给机器装上“职业操守”写完这篇长文回看标题“agency-agents”我越来越觉得它指向的不仅是技术架构的演进更是一种工程哲学的成熟。过去十年我们痴迷于让机器“更聪明”——更大参数、更多数据、更强推理。但 agency-agents 提醒我们光聪明不够还得有“职业操守”。一个医生 agent它的 agency 不是“能诊断多少种病”而是“在不确定时敢于说‘需要会诊’在资源紧张时懂得优先救治危重病人面对不合理的指令时能坚守诊疗规范”。一个客服 agent它的 agency 不是“能回答多少个问题”而是“在用户愤怒时主动升级发现知识盲区时诚恳告知遇到系统故障时清晰说明影响范围而非推诿”。这种操守无法靠 prompt engineering 注入也无法靠 fine-tuning 灌输。它必须被编码为可执行的策略、可验证的契约、可审计的状态。它要求我们放下“上帝视角”的调度幻想转而相信当每个组件都清晰知道自己是谁、要什么、能做什么、不能做什么、如何与他人相处时整个系统反而会涌现出超越设计的韧性与智慧。我在某高校的实验室墙上看到过一句手写的标语“Trust the agents, not the orchestrator.” —— 我把它抄了下来贴在自己的显示器边框上。这大概就是 agency-agents 给我最深的触动不是造出更强大的工具而是学会与一群有原则、有边界、有尊严的数字同事共同工作。
