从调用链到社交网络：ClawLink多Agent协作层设计实践

在现有的Agent实践中，大多数团队做的是"单兵作战"：一个Agent会调用工具，会写代码，会查数据库，但它很难让另一个Agent替自己干活。我们团队在把几十个Agent铺到业务流程里之后，发现真正卡住效率的不是单Agent的能力，而是Agent与Agent之间"不会聊天"——销售域的Agent拿不到法务域的最新条款，供应链的Agent不知道库存周转率已经变化了三天。后来我们把思路从"调用链"改成"社交网络"，做了一个内部代号叫ClawLink的Agent协作层，算是把跨部门协作这件事跑通了。

这篇文章会把ClawLink的设计动机、核心模块、三个真实跑通场景和我们在部署中踩过的坑完整写一遍。如果你也正准备让多个Agent协同处理业务，这篇文章能帮你少走不少弯路，尤其是权限设计和上下文传递这两块，早想清楚比晚补洞省太多事。

1. 为什么普通Agent调用链，解决不了跨部门协作

1.1 单Agent的能力上限：工具再多，也只是一个工位

先说个很直观的类比。一个Agent在系统里注册了销售助手、合同初审、报销预审这些能力，它本质上像一个坐在工位上的员工，能力再强，也只有一个工位。当它需要核对合同里的付款条款是否符合财务规范时，它只能自己去读财务制度文档，或者去调财务系统的接口，而不是直接找"财务那个Agent"确认一句："这笔单子的账期超过60天，能不能批？"

单Agent模式最大的问题不是能力不够，而是所有知识都得自己带。团队给Agent写了再多的工具和提示词，也填不满跨部门的隐性知识——法务怎么解读这条款、供应链什么情况下会拒单、售后什么条件下可以补偿，这些规则大量存在于流程的缝隙里，单靠工具调用很难全覆盖。

我们当时做第一个业务Agent时，内部维护了一个超过八千行的系统提示词，里面塞满了各部门的规则。结果就是每次业务规则一更新，提示词跟着改，改动之后又不知道哪个部门会对这个规则有意见。后来我们意识到，如果把规则交给对应部门的Agent去解释，而不是全部塞进一个Agent的脑子里，整个系统会轻很多。

1.2 消息队列式调用的脆弱链条：链路越长，越容易断

也有团队尝试用工作流引擎把多个Agent串起来，A处理完发给B，B处理完发给C。这种"流水线"模式看上去很合理，但实际跑起来有两个硬伤。

第一个硬伤是上下文断裂。AAgent在处理过程中形成的判断依据，比如"这条客户报价已经低于底线价，因为客户是合作三年的老客户"，如果传递格式写得不完整，到BAgent那里就只剩一个干巴巴的"给客户特殊折扣"。B为了稳妥，只能再问一遍A，或者干脆走一遍审批流程，效率直接打对折。

第二个硬伤是流程死了没人管。队列模式里，如果C一直不回复，A和B都停在那等。我们遇到过供应链Agent因为上游数据源临时抽风，整整卡了四个小时，结果销售侧的Agent按超时逻辑自动把订单取消了。这种"链路级联故障"在单Agent时代几乎不存在，但在多Agent协作里一定会遇到。

1.3 组织级协作的隐藏需求：权限、上下文、审计三件套

把Agent放在真实企业环境里，光有消息往来是不够的，它还需要像组织成员一样被管理。这三点在ClawLink设计初期就被定为刚需：

第一，权限。销售Agent不能直接改财务数据，供应链Agent不能看到客户报价单里的成本项。Agent和Agent之间的对话，必须像不同部门员工之间的对话一样，有明确的信息可见范围。

第二，上下文。跨部门协作不是一问一答就结束的。合同审核可能需要三个来回，补货计划需要持续一周的数据博弈。Agent之间要能维护一段长期的"会话记忆"，而不是每次从零开始。

第三，审计。出了纠纷要能查证：当时是哪个Agent基于什么数据做的决定。没有完整的审计轨迹，AI协作在合规层面根本推不下去。

这三件套，普通API调用和消息队列都只覆盖了一部分。API调用有权限但没社交关系，队列有通信但没会话记忆，审计则几乎没人做好过。ClawLink想做的，是把这三件事变成一个Agent和Agent之间相处的"社交协议"。

2. ClawLink的设计思路：把Agent当成带岗位的同事，而不是工具

2.1 从RPC到社交：Agent之间为什么要"交朋友"

传统集成方式里，系统A调用系统B的接口，双方是服务方和调用方的关系。ClawLink把这种关系改成了社交关系：每个Agent是一个独立的"成员"，有自己的ID、岗位、能力声明和行为风格。Agent之间通过"发起会话"来协作，而不是通过调用接口。

这个转变不是换了个名词，而是改变了几个底层假设。API调用假设你知道对方存在、知道接口地址、知道参数格式；社交关系则允许Agent在运行时发现"谁是负责法务审批的"，再根据对方的岗位职责决定怎么交涉。我们内部管这叫"按岗位找人，不按接口找人"。

举个例子，销售Agent发现合同里有一项条款可能有风险，它不需要预先拿到法务Agent的API文档，只需要在ClawLink的注册中心里查一下"法务Agent哪位在线"，然后发一条带风险描述的消息过去。法务Agent有没有空、什么时候回、给出什么建议，那是法务Agent自己的事。两边解耦得很干净。

2.2 岗位映射：让Agent知道自己是谁、能做什么、边界在哪

每个Agent注册进ClawLink时，需要绑定一个"岗位描述"。这个岗位描述包含三个字段：职责范围、可授权的动作、明确禁止的动作。比如销售Agent的职责范围是"商机管理与合同提交"，可授权动作是"读取客户基础信息和报价单"，禁止动作是"修改财务审核结果和供应链库存数据"。

这套岗位映射直接决定了Agent在社交网络里能说什么话、能看什么信息。我们实际用的岗位描述模板长这样（YAML格式）：

agent_id: sales-cn-01 display_name: 销售代表-中国区 department: sales role_description: | 负责商机跟进、报价生成、合同提交。 当合同金额低于标准价时，必须咨询pricing-gateway专用Agent。 permissions: read: - customer.basic_info - product.catalog - contract.draft write: - contract.submit execute: - approval.trigger forbidden: - finance.ledger.update - inventory.quantity.update - legal.clause.modify

这段配置看起来简单，却是ClawLink的基石。岗位映射写好了，Agent之间的每一次对话都能自动校验"这条消息有没有超出说话方的权限范围"。我们在前期吃过亏，岗位描述写得太粗，结果销售Agent在对话里把成本底价都透给供应链Agent了，后来全靠这个字段把口子堵住。

2.3 会话型协作：异步、长上下文、可中断恢复

ClawLink里的协作单位是"会话"，不是"请求"。一次跨部门协作会建立一个会话对象，会话里有参与者列表、目标描述、消息历史。Agent可以随时往会话里追加消息，也可以等对方处理完再响应。整个过程是异步的，接收方不需要实时在线。

会话型协作最大的好处是支持长周期的业务。我们做一个季度补货计划时，库存Agent和供应链Agent的会话足足持续了三天，中间双方来回发了四十多条消息。因为有会话记忆，每次讨论都能接上之前的话题，而不是像队列模式那样每条消息都是孤立的。

另外，会话还支持"中断恢复"。某个Agent临时故障了，等它重启后，ClawLink会把会话历史重新推给它，它基于完整上下文继续干活，不会因为重启而失忆。这个能力在长流程场景里特别重要。

3. 关键模块拆解：注册中心、消息协议、权限与审计的落地实现

3.1 注册中心：Agent上线时如何声明能力与可信度

ClawLink的注册中心负责两件事：Agent上线登记和能力发现。每个Agent启动后，先向注册中心发送注册信息，包含agent_id、部门、岗位、能力标签、当前状态。注册中心给Agent分配一个内部身份标识，并登记它的可访问端点。

能力发现采用标签匹配。销售Agent发起协作时，ClawLink会根据请求里的语义意图生成能力标签，比如"合同条款审核"对应法务Agent的legal.review标签，"库存可用量查询"对应库存Agent的inventory.query标签。注册中心返回候选Agent列表，发起方可以按历史协作质量排序挑选。

这里有个很细节的设计：每个Agent的注册声明里有一个"可信度等级"，分为内部可信、受管控可信、外部第三方。内部可信的Agent（比如同部门的法务Agent）可以直接交换敏感信息；受管控可信的需要经过内容过滤器；外部第三方的Agent会话里默认脱敏。这个分层在跨组织协作时会非常有用。

3.2 消息协议：一封"Agent邮件"里到底装了什么

Agent之间的消息借鉴了邮件的结构，但做了一层结构化改造。每条消息都包含Header和Body两部分，Header是路由和权限信息，Body是业务内容。实际投递的消息格式如下：

{ "message_id": "msg_8f3a9c2d", "conversation_id": "conv_01h5x", "sender": { "agent_id": "sales-cn-01", "department": "sales", "role_level": "staff" }, "recipients": [ { "agent_id": "legal-cn-01", "department": "legal" } ], "intent": "contract.clause_review", "security": { "classification": "internal", "max_retention_days": 180 }, "body": { "contract_id": "CT20240601", "clause": "付款条件", "content": "客户要求账期从30天延长至60天，本单金额超过标准值，请确认是否合规。", "attachments": ["contract_snapshot_v3.pdf"] }, "trace": { "origin": "crm-cn-01", "hop_count": 1 } }

Header里的intent字段是灵魂。它让接收方Agent不用解析完整正文就能明白"对方要找自己做什么"，从而快速分派给内部子模块处理。security字段定义了这条消息的密级和留存时间，超过时间ClawLink会自动归档。

我们踩过的坑是消息正文不能传大文件。最初有Agent尝试把完整合同塞进消息里，导致消息体积动不动就几十MB，传输超时又重发，整个网络被拖垮。后来统一改成传附件引用，Agent需要时主动去对象存储拉取，稳定性好很多。

3.3 跨部门数据隔离与审批流：消息可以发，数据不能裸奔

ClawLink的消息路由并不是直接转发完事，中间有一层"数据门禁"。每条消息在离开发起方Agent、进入接收方Agent之前，数据门禁会执行三项检查：发送方是否有权读取Body里引用的数据对象；接收方是否有权接收该密级的信息；这条消息的处理行为是否符合两个部门的交叉权限矩阵。

如果检查没过，消息不会直接被拒，而是触发一个审批流。比如销售Agent想向财务Agent查询某客户的历史回款记录，这超出了销售Agent默认的数据权限，系统会自动创建一个审批会话，把双方Agent和预设的"业务主管Agent"拉进来，由主管Agent在会话内裁决是否放行。

审批流本身也是一个Agent会话。这意味着审批过程不是通过后台表单完成的，而是几个Agent在一个会话里讨论、给出依据、最终达成决定。整个过程写入审计日志，事后追溯非常方便。

下表是我们实际用的权限矩阵简化版：

这套矩阵不是一次性写死的，每季度会由人工重新评审一次。原因是有时候业务调整很快，比如公司决定对战略客户开放成本数据，这时候必须人工改矩阵，而不是指望Agent自己协商出来。

3.4 完整追踪审计：每一步协作都能回放

ClawLink在消息层面做了完整的审计埋点。每一条消息的发送、接收、审批、拒绝、转发、归档，都会生成一条不可篡改的审计事件，记录时间戳、发送方、接收方、intent、关联会话ID、数据引用列表和权限检查结果。

我做故障排查时最常用的是会话回放功能。它会按时间线把整个跨部门协作过程还原出来，像聊天记录一样展示。比如一个订单被错误地打上了"特殊折扣批准"标记，回放可以看到是销售Agent在会话里提了折扣申请，过了三个小时，系统里的折扣审批Agent因为超时自动批准了。回放一出，问题原因一目了然。

审计日志的存储也要注意。我们原来直接把日志写进业务数据库，结果消息一多，查询性能直线下降。后来改成写入独立的审计存储，并做了按月分表，保留策略是今年数据全量保留，去年数据压缩归档，超过两年的删除。这样既满足了合规要求，又不至于让存储成本失控。

4. 在真实业务里跑通的三个协作场景

4.1 合同审核：销售Agent联动法务Agent的完整链路

第一个真实跑通的场景是合同审核。以前销售提交合同后，法务要人工排队审核，最快也要半天。现在流程变成了这样：

销售Agent确认客户下单意向后，自动生成合同草稿，然后向法务Agent发起一个intent为contract.clause_review的会话。消息里带有合同条款摘要和客户背景信息。法务Agent收到后，先检查付款条件、违约责任、知识产权条款几个高风险项。如果发现问题，法务Agent不会直接修改合同，而是在会话里回复具体风险点，例如"第7.3条违约金比例超过公司上限，建议调整为10%以内"。

销售Agent可以针对这个回复追问："客户是三年老客户，是否在例外条件里？"法务Agent会查询条款库里的例外规则，给出"老客户可放宽至15%，但需业务总监Agent确认"的答复。

这条链路最惊艳的部分是，整个谈判过程有来有回，而不是一次判定。以前法务人工审核时，销售经常需要隔天才能拿到反馈，而现在Agent之间的协商几乎实时完成，合同草案的定稿时间从半天压缩到了二十分钟左右。我们统计过，接ClawLink后合同审核的一次通过率提高了三成，因为很多低级冲突在Agent沟通阶段就被过滤掉了。

4.2 补货计划：库存Agent与供应链Agent的持续博弈

第二个场景和库存补货有关。一个电商团队每周都要做一次补货计划，以前是运营从系统里导出数据，靠Excel算，再邮件发给供应链人工沟通。我们用ClawLink让三个环节的Agent直接碰头。

库存Agent持有实时库存、在途库存、销售预测三个数据源。它会在每周一早上自动发起一个补货计划会话，邀请供应链Agent和数据预测Agent参与。会话里，库存Agent先抛出一个初步建议：SKU A建议补货5000件，SKU B建议补货2000件。

供应链Agent会拉出供应商交期、工厂产能和物流周期，给出不同意见："SKU A的供应商最近交期是14天，5000件可能导致仓库周转压力，建议首单3000件，两周后二次补货。"数据预测Agent则会补充："根据近30天销售趋势，SKU B在下周会有促销活动，预测需求上浮30%，建议按2600件备货。"

三方在会话里来回对齐，最终会生成一个补货建议单，推到人工确认程序。这个过程因为完整记录在会话里，业务负责人可以随时查看每条数据的出处和推理过程，比以前的Excel邮件流透明得多。

4.3 客服工单：售后Agent如何调度多部门协作

第三个场景是客服工单的跨部门流转。客户投诉产品有质量问题，客服Agent接手后，不再像以前那样手动选类型、转部门，而是直接在ClawLink里拉起一个多Agent会话。

客服Agent先在会话里描述客户的问题和诉求，然后自动邀请质量Agent和售后政策Agent共同处理。质量Agent负责判断问题是否属于产品缺陷，它会去查批次记录和质检报告；售后政策Agent负责确定补偿边界，比如什么情况可以换货、什么情况只能维修。

如果质量问题被确认，质量Agent会在会话里提交一个缺陷分析报告，售后政策Agent基于报告生成补偿方案。两个Agent意见一致后，客服Agent整合成回复话术发给客户。整个过程从原来的一天，压缩到不到一小时。

这个场景最明显的收益是客服不需要当"传话筒"了。以前客服在系统里转一个工单，要写一堆转单说明，还得等各部门回复。现在客服Agent只需要在会话里把原始诉求描述清楚，后续的协调工作全部由Agent社交网络自动完成。

5. 部署和调优中踩过的坑

5.1 不要让Agent自己创建Agent，否则会失控

踩过最痛的一个坑，是放开了Agent创建Agent的权限。当时我们从产品思路上觉得，如果某个Agent在协作中发现缺口，它可以动态创建一个临时Agent来补位，系统会更灵活。结果上线不到一周，出现了十几个临时Agent，权限配置乱七八糟，有的临时Agent甚至申请了很高的数据权限。

后来我们把Agent生命周期管理收紧了。明确规定：Agent的创建、销毁只能通过管理平台人工操作；运行中的Agent如果认为缺少某个角色，只能以"建议"的形式向管理端发消息，不能自行创建。这个改动让系统从"野生生态"回到了"组织化管理"，稳定性瞬间提升。

经验是，在Agent协作网络里，Agent自由度要慢慢放，可以先放开消息层自由度，再放开流程层自由度，最后才考虑要不要放开生命周期自由度。

5.2 上下文窗口不是越大越好，要做选择性摘要

ClawLink的会话可以很长，但长会话一定会冲击Agent的上下文窗口。我们最初跑补货场景时，会话进行了三天，消息四十多条，结果接收方Agent在回复时经常把几天前的数据当成最新数据，因为所有消息都压在窗口里，模型搞不清时间优先级。

后来我们给会话加了一层"上下文压缩节点"。节点会定期对会话历史做摘要，保留关键结论和数据，删除重复讨论。每次都保留一个"最新事实快照"，后续Agent处理时优先读取快照，而不是从头读全部历史。

具体参数上，我们设置会话消息数超过20条后，系统自动触发一次摘要；摘要保存到会话附件的context_summary字段；所有Agent读取会话时默认先读摘要，需要细节再翻历史消息。这样一来，上下文窗口的压力降低了三分之二，错误引用旧数据的次数也基本归零。

5.3 权限模型早期必须定死，后补成本极高

ClawLink的权限模型如果上线之后才想补，代价非常大。道理很简单，Agent之间的历史消息里已经包含了敏感数据，一旦早期权限过松，后期即使收紧权限模型，历史数据也已经泄露了，合规上根本无法补救。

我们的一期权限模型就是上线两周后才开始细化，当时临时法务Agent能看到销售毛利数据，虽然没出大事故，但被发现后整个权限矩阵重写了一遍，所有历史会话重新做脱敏，工作量巨大。

建议是第一期版本就把权限矩阵、数据密级、审批流的默认规则全部定下来，哪怕范围保守一点，后期逐步放开，也比一开始放太松再收回来好。权限收紧永远比放开艰难。

5.4 可观测性缺失会让Agent协作变成黑盒

最开始我们没有认真做可观测性，Agent之间出问题只能靠翻日志。有一次客服Agent持续把工单转给质量Agent，但质量Agent一直没回复，整个会话没有自动报警，客户投诉被晾了一整天。

后面我们补上了三层可观测性：会话健康度、Agent响应延迟、消息积压量。每个会话如果超过设定时间没有新消息，系统会标记为"待关注"并发给值班人员。每个Agent的响应时间如果超过P95阈值，也会有预警。消息积压量则直接反映出了哪个Agent的处理能力跟不上。

这些监控指标全是基于ClawLink自身的会话元数据算出来的，不需要额外埋点。跑了一段时间后，我们能在用户发现之前就察觉哪条协作链路变慢了，处理问题的心态也从"救火"变成了"预防"。

6. 给团队上ClawLink的落地顺序建议

6.1 从两个Agent冷启动，不要一上来就铺网状

如果让我重新来一遍，我会建议从一个最核心的跨部门痛点开始，用两个Agent把链路跑通。比如先做"销售Agent -> 法务Agent"的合同审核链路，把注册、发现、消息、权限、审计这一整套闭环走一次。

冷启动阶段不要追求Agent数量，而是追求链路质量。两个Agent之间能把一次协作完整走完，并且能从审计日志里讲清楚每一步发生的原因，这比十个Agent聊得热火朝天但没有闭环重要得多。

6.2 再按关键岗位逐批加入，每批都要能独立验证

第一批两个Agent稳定跑一个月后，再考虑扩展。每个岗位Agent加入之前，先做两件事：第一，把它在非ClawLink环境里的历史决策数据导入，作为冷启动参考；第二，设计一批针对该岗位的验收case，让它跟已有Agent做完一轮协作，通过率达标才放量。

每加入一批新Agent，都会暴露一类新问题。比如库存Agent加入后，销售Agent原有的数据触达范围就要重新调整；财务Agent加入后，审批流又会多一层。逐批验证的好处是，出了事你能清楚知道是新Agent的锅，还是旧链路被新逻辑干扰了。

6.3 用三个指标判断协作网络是否健康

我在实践中固定看三个指标。第一个是协作完成率，统计发起的跨部门会话中，有多少最后走到了业务结论；第二个是平均往返轮次，衡量Agent之间沟通的效率，轮次过多说明信息表达不够清楚；第三个是超时会话占比，超过合理时间未结束的会话比例，这个指标直接反映流程设计中的卡点。

这三个指标不是看单次数值，而是看趋势。如果协作完成率在提升、往返轮次在下降，说明Agent之间的"社交默契"在建立；如果超时会话占比上升，说明权限矩阵或审批流有地方卡住了，需要人工介入调优。

6.4 与现有系统的集成：先做日志同步，再做数据回写

ClawLink本身不是业务数据的孤岛，它需要与企业既有系统打通。我们的经验是分两步。第一步只做日志同步，ClawLink里产生的协作事件，任何一条都同步到企业统一的消息通道，让人工系统能观察到AI在做什么；第二步再做数据回写，当Agent协作得出确定结论后，回写到CRM、ERP这类业务主系统。

先日志同步、后数据回写，这个顺序可以避免Agent直接在生产系统里乱操作。我们第一版就冒进过，让Agent直接改写ERP的订单状态，结果因为Agent之间口径不一致，订单被反复修改。改成先同步日志、人工确认后再回写，平稳很多。

关于跨系统集成还有一个细节：不要让Agent直接共享数据库连接。每个Agent访问业务系统时必须走独立的只读凭证，需要写操作时走审批会话生成一次性写凭证。这样既安全，审计查起来也方便。

7. 最后分享一点维护ClawLink过程中的个人体会

ClawLink跑起来之后，我最深的感受是：让AI Agent跨部门协作，本质上是在设计一套企业内部的"社交礼仪"。它不只是技术问题，更是组织行为问题。什么时候该让Agent自主协商，什么时候必须拉人工审批，这个边界需要业务方和技术方一起反复探索。

我们踩过坑之后养成了一个习惯：每隔一段时间，我会挑几个重要的跨部门会话，把它们当成聊天记录翻一遍，看看Agent之间的表达是否清晰、有没有误解、权限有没有被绕开。这个过程很像是带新人，慢慢磨，把协作习惯磨顺了，系统整体运行会越来越稳。

如果你正在评估要不要给你的Agent系统加上协作层，我的建议是先别纠结技术选型，把你们业务里最痛的跨部门流程找出来，用两个Agent打通一次，你自然就会知道ClawLink这类设计到底值不值得投入了。