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，响应延迟 ≤5s，token 成本高；
• 平衡模式：使用量化模型 + 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} }

这个架构天然规避了单点故障。没有 manager，agenda 通过 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 metric='cpu_percent' AND timestamp > ?", (datetime.now() - timedelta(minutes=5),)) avg_cpu = cursor.fetchone()[0] or 0 # 查询本地任务队列长度 cursor.execute("SELECT COUNT(*) FROM task_queue WHERE status='pending'") 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(hours=2)).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 (?, ?, ?, ?, ?)", (f"t_{int(datetime.now().timestamp())}", request['initiator_id'], proposal['task'], 'pending', datetime.now()) ) conn.commit() conn.close() return {"status": "accepted", "task_id": f"t_{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 设计了四张核心表：

所有表的操作都封装在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 某公司客户响应中台：高并发下的弹性降级与契约履约

场景：电商大促期间，客服响应 agent（support-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}

第一条事件通知运维团队“系统已降级”，第二条事件则精准告知知识库 agent（knowledge-agent）：“我们的 SLA 违约了，原因是我变慢了，不是你不行”。knowledge-agent收到后，没有恐慌式扩容，而是启动自己的预案：它将高频问题的缓存 TTL 从 1 小时延长至 24 小时，并向support-agent发送一条协商消息：“我已延长缓存，你可减少 30% 的实时查询，专注提升首响”。这是两个 agency-agents 基于契约的协同自愈，而非单方面的救火。

陷阱警示：早期版本中，support-agent在降级时会直接关闭与knowledge-agent的连接，导致后者误判为宕机而触发告警。后来我们强制所有 agent 在状态变更时，必须向所有签约 partner 发送state_announcement事件，明确告知“我还在，只是模式变了”。这个小小的通信约定，大幅降低了误告警率。

4.3 某实验室工业设备预测维护系统：长周期任务中的状态漂移与重校准

场景：为一台精密光学设备部署预测维护 agent（pm-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；
• 同时，向实验室的专家 agent（expert-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→failed）；detect-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 次快速重试，进一步加剧了拥塞。这暴露了两个致命缺陷：一是协商协议没有成本约束，二是没有优雅的失败回退。

修正路径：为所有协商交互添加三层防护：

1. 频率熔断：每个 agent 维护一个negotiation_rate_limiter，记录过去 60 秒内向同一 partner 发起的协商次数，超过 5 次则拒绝新请求，返回{"status": "rate_limited", "retry_after_sec": 30}；
2. 负载感知：在协商请求头中加入X-Agent-Load: high/medium/low，由发起方根据自身 CPU/队列长度设置；接收方若负载为high，可直接返回{"status": "deferred", "retry_suggestion_sec": 120}；
3. 契约兜底：当协商失败超过 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 Broker（DAB）提供标准化访问。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 给我最深的触动：不是造出更强大的工具，而是学会与一群有原则、有边界、有尊严的数字同事，共同工作。