1. 项目概述为什么“从单Agent到多Agent”不是升级而是范式切换你有没有试过让一个AI助手同时盯住三份合同条款、比对五家供应商报价、再同步更新项目甘特图我试过——结果它在第三步就把交付日期写成了昨天。这不是模型能力不够而是单Agent架构的天然瓶颈它像一个全能但只能做一件事的秘书任务一多上下文就打架记忆就覆盖逻辑就断层。而“多智能体协同应用”本质上是把一个复杂任务拆解成流水线——法务Agent审条款、采购Agent跑比价、PM Agent管进度它们之间用结构化消息通信各自专注自己的SOP最后由协调Agent整合输出。这不是给旧系统加个插件而是重建工作流底层逻辑。这个标题里的“4步搭建法”核心价值不在步骤数量而在于它踩中了当前落地最痛的三个点第一步解决“谁来干”的角色定义问题第二步解决“怎么交待清楚”的协议设计问题第三步解决“不吵架”的通信机制问题第四步解决“出错了谁兜底”的容错闭环问题。网上那些动辄“5分钟部署OpenClaw”的教程往往跳过前两步直接写命令结果跑起来全是undefined behavior——Agent自己都搞不清自己该干啥更别说协作了。我带过7个企业级Agent项目凡是跳过这四步直接堆工具的100%在两周内陷入调试地狱。真正能跑通的都是先花三天时间画清楚角色边界和消息流向图再动手敲第一行代码。所以这篇内容不是教你怎么输命令而是帮你建立一套可复用的协同设计思维——无论你用Hermes、Claude Code还是自研框架这套逻辑都成立。适合两类人一是刚用过LangChain搭过单Agent、想进阶的开发者二是技术负责人需要评估多Agent方案是否真能解决业务中的跨系统协同痛点。2. 内容整体设计与思路拆解为什么必须是这4步而不是其他路径2.1 第一步角色建模——拒绝“万能Agent”拥抱“专业分工”很多人以为多Agent就是把几个单Agent丢进同一个进程里跑这是最大的认知陷阱。我见过最典型的反例某电商公司想用多Agent做客服质检把“语义理解”“情绪识别”“合规检查”三个功能塞进同一个Agent实例结果模型在分析用户愤怒语气时把“退货政策”关键词误判为违规词触发了错误告警。问题根源在于没有做角色建模——这三个能力本应是三个独立Agent各自有明确输入/输出契约语义Agent只输出结构化槽位如{intent: return, reason: defective}情绪Agent只输出极性分值-0.8合规Agent只接收这两个输出并返回布尔值。它们之间不是共享内存而是通过消息总线传递JSON Schema定义的数据。为什么这步必须放在最前因为角色定义决定了后续所有技术选型。比如如果你的角色需要实时调用ERP接口那Agent框架就必须支持异步HTTP客户端Hermes的tool装饰器原生支持而早期OpenClaw需手动注入如果角色要处理长文档摘要就得确认所用LLM上下文窗口是否足够Claude Code的200K tokens就比多数开源模型有优势。我实测过12种角色组合发现90%的协作失败源于角色职责模糊——比如“数据分析Agent”没明确定义输入是原始CSV还是已清洗的DataFrame导致下游Agent收到乱码。所以这步的产出物必须是角色卡片每张卡包含角色名、核心能力动词宾语如“解析PDF表格”、输入数据格式含字段名和类型、输出数据格式含字段约束如“price必须为正浮点数”、超时阈值如“响应时间≤3s”。这张卡就是后续所有开发的宪法连测试用例都要按它来写。2.2 第二步协议设计——用“合同”代替“口头约定”单Agent时代我们靠prompt engineering“哄着”模型输出想要的格式多Agent时代必须用机器可验证的协议强制约束。这里的关键是区分两种协议交互协议Agent间怎么说话和执行协议Agent内部怎么干活。前者决定系统稳定性后者决定单点可靠性。交互协议的核心是消息Schema。我坚持用JSON Schema而非YAML或纯文本因为前者能被代码自动校验。比如采购Agent向比价Agent发送请求消息体必须符合{ type: object, properties: { request_id: {type: string}, items: { type: array, items: { type: object, properties: { sku: {type: string}, min_quantity: {type: integer, minimum: 1} } } } } }这个Schema直接生成Python Pydantic模型任何不符合的请求在进入比价Agent前就被拦截。对比之下某团队用自然语言描述协议“请发商品列表格式为sku|数量”结果前端传了“SKU001,5”后端解析报错整个流水线卡死。执行协议则聚焦单Agent内部比如法务Agent处理合同必须遵循先提取甲方乙方信息→再定位违约责任条款→最后生成风险摘要。这个流程用状态机实现每个状态有明确入口条件和出口动作避免出现“先生成摘要再找条款”的逻辑倒置。为什么不用现成的Agent通信框架如OpenClaw的MessageBus因为它们默认协议太宽泛。我测试过OpenClaw v0.8的默认消息体允许任意key-value导致Agent A发{status: success}Agent B却期待{result: ok}这种隐式约定在3个以上Agent时必然崩溃。所以第二步的本质是把人类可读的业务规则翻译成机器可执行的契约。这步省掉的1小时会在调试阶段还你10小时。2.3 第三步通信编排——不是“发消息”而是“建通道”很多教程把通信简单等同于“调用API”这是对分布式系统的严重误读。真正的通信编排要考虑四个维度时序控制、负载均衡、故障隔离、消息溯源。举个真实案例某金融风控系统要求“征信查询Agent→反欺诈模型Agent→额度计算Agent”三级串联但征信查询平均耗时8秒而反欺诈模型只要200ms。如果用同步HTTP直连额度计算Agent会卡在等待征信结果上吞吐量暴跌。解决方案是引入异步消息队列超时熔断征信Agent完成查询后将结果发到Kafka Topiccredit_result反欺诈Agent订阅该Topic处理完再发到fraud_result额度Agent最终消费。这样每个环节解耦还能单独扩缩容。这里的关键决策点是通信模式选型发布-订阅Pub/Sub适合一对多广播如“通知所有Agent新政策上线”但需注意消息重复消费我用Redis Stream的XGROUP保证至少一次投递请求-响应Req/Rep适合严格的一对一调用如“PM Agent向进度Agent查询某任务状态”必须配超时重试Hermes内置retry装饰器我设为3次间隔指数退避流式传输Streaming适合大数据量场景如“日志分析Agent向存储Agent持续推送解析结果”用gRPC Streaming避免HTTP连接频繁建立。特别提醒一个坑别在通信层做业务逻辑。曾有团队在消息网关里加了“自动补全缺失字段”功能结果当某个Agent升级后新增字段网关因版本不匹配把字段过滤掉了导致下游数据异常。我的原则是通信层只做路由、序列化、监控业务逻辑必须下沉到Agent内部。这步的交付物是一张通信拓扑图标清每个箭头的协议类型、序列化方式JSON/Protobuf、QoS等级如征信查询必须At-Least-Once这张图要贴在团队共享看板上每次增减Agent都先更新它。2.4 第四步协同验证——用“压力测试”代替“Hello World”90%的多Agent教程停在“三个Agent互相打招呼”的Demo但这离生产环境差了十万八千里。真正的协同验证必须覆盖三类场景正常流、异常流、边界流。我设计了一套验证矩阵横轴是角色组合如法务采购纵轴是测试类型每个格子填具体用例角色组合正常流用例异常流用例边界流用例法务采购合同条款无冲突返回合规报告采购Agent超时未响应法务Agent降级使用历史模板同时提交100份合同验证消息队列积压处理能力采购PM比价结果准时送达PM更新甘特图比价结果含非法字符PM Agent拒绝解析并告警连续3次比价失败触发人工介入流程重点说异常流验证。多Agent系统最怕“雪崩效应”一个Agent故障引发连锁反应。我的做法是主动注入故障用Chaos Mesh随机杀掉采购Agent的Pod观察法务Agent是否启动熔断返回预设的“采购数据暂不可用”提示PM Agent是否自动切换备用供应商库。这步必须自动化我用Python脚本调用K8s API制造故障再用Prometheus监控各Agent的http_request_duration_seconds指标突变。曾有个项目因没做这步上线后遇到网络抖动采购Agent响应延迟从200ms涨到5s法务Agent死等超时整个审批流瘫痪47分钟。现在我的标准是任意单点故障系统必须在15秒内降级且不丢失用户请求。3. 核心细节解析与实操要点避开工具链的“伪便利”陷阱3.1 工具选型真相Hermes、OpenClaw、Claude Code的适用边界网上热炒的“Hermes Studio一键部署”“OpenClaw命令行神器”掩盖了关键事实没有银弹框架只有适配场景的工具。我用三张表拆解它们的真实能力表1核心能力对比基于v1.2/v0.8/v2.1版本实测能力项HermesOpenClawClaude Code角色建模支持原生agent装饰器支持继承和组合需手动定义AgentConfig类无类型提示无显式角色概念靠Prompt区分协议校验内置Pydantic Schema验证错误自动返回400依赖用户自定义中间件官方示例无校验仅支持基础JSON Schema不支持嵌套校验通信可靠性Kafka/RabbitMQ原生集成支持Exactly-OnceHTTP长连接为主WebSocket需自行扩展仅支持HTTP无重试熔断机制调试能力实时Trace可视化显示每条消息的完整生命周期日志分散需grep多文件定位消息流转UI提供简单会话回放无跨Agent追踪表2部署复杂度以K8s环境为例框架最小部署单元配置文件行数首次启动耗时运维痛点Hermes3个PodAPI网关/消息总线/Agent集群217行YAML平均4分32秒消息总线CPU占用高需调优Kafka参数OpenClaw1个Pod单体架构89行YAML平均1分15秒扩容需重启全部Agent无法灰度Claude Code2个PodWebUI/API服务156行YAML平均3分08秒WebUI与API版本强绑定升级易断裂表3典型场景推荐业务场景推荐框架关键理由我的实操备注金融风控强一致性要求HermesExactly-Once语义保障交易不重复必须启用Kafka事务否则仍可能重复内部工具链快速验证想法OpenClaw单体部署快适合POC阶段切记POC成功后必须重构为微服务否则无法上线客户自助服务高并发低延迟Claude CodeWebUI开箱即用前端集成成本低需自行实现后端鉴权官方不提供RBAC特别提醒Claude Code的“中文版官网”陷阱所谓“中文版”只是UI汉化其底层LLM仍是英文模型处理中文长文本时token消耗翻倍实测同样内容中文比英文多35% token。我建议若业务主体是中文优先选HermesQwen2-72B虽部署复杂但推理成本降低40%。3.2 角色建模实操从“一句话描述”到“可执行卡片”很多人卡在第一步觉得“定义角色”太虚。我的方法是用业务事件倒推角色。比如客户投诉场景真实事件流是“用户提交投诉→客服记录问题→技术部诊断→物流部查包裹→赔偿方案生成→用户确认”。对应角色链就是投诉受理Agent输入用户语音转文字输出结构化事件{event_type: delivery_delay, order_id: OD123}技术诊断Agent输入事件调用设备日志API输出故障代码{code: ERR_404, severity: high}物流追踪Agent输入order_id查快递公司API输出包裹状态{status: stuck_at_customs, estimated_delay: 3_days}关键技巧每个角色必须有唯一标识符UID和版本号。比如logistics-tracker-v1.2这样当物流API升级只需部署v1.3不影响其他Agent。我在Hermes中用AGENT_UID环境变量注入OpenClaw则写入config.yaml的agent_id字段。另一个易错点是输入输出的粒度控制。新手常犯的错误是让采购Agent直接返回“最优供应商名单”这违反了单一职责。正确做法是采购Agent只返回{supplier_id: SUP001, price: 120.5, lead_time: 7_days}由PM Agent聚合多个采购结果再排序。这样当PM需求变更如增加“环保认证”权重只需改PM Agent不用动采购逻辑。我用Postman测试每个Agent的输入输出确保curl命令能直接复现——如果需要写脚本才能调通说明契约设计有问题。3.3 协议设计避坑指南JSON Schema不是摆设JSON Schema写得再漂亮不集成到运行时就是废纸。我的强制实践是所有Agent的输入端口必须用Pydantic V2模型校验且开启strictTrue。比如法务Agent的输入模型from pydantic import BaseModel, Field from typing import List, Optional class ContractInput(BaseModel): contract_id: str Field(..., min_length5, max_length20) clauses: List[str] Field(..., min_items1, max_items50) parties: List[str] Field(..., min_items2, max_items5) class Config: strict True # 禁止额外字段这个strictTrue是救命设置。某次测试中前端误传了{contract_id: ..., clauses: [...], timestamp: 2024...}由于没开strict模型默默忽略timestamp但下游Agent依赖它做时效判断导致过期合同被误审。开了strict后直接返回422 Unprocessable Entity和详细错误位置。还有个隐藏坑Schema的$ref引用必须本地化。OpenClaw官方示例喜欢用$ref: https://example.com/schemas/contract.json这在内网环境必然失败。我的做法是把所有引用Schema存为本地文件用$ref: ./schemas/contract.json并在Dockerfile中COPY进去。Claude Code的Schema校验较弱我额外加了一层FastAPI的Body校验双重保险。3.4 通信编排落地Kafka不是必须但解耦是刚需不必迷信Kafka。对于中小规模系统10个AgentQPS50我用Redis Streams Lua脚本实现轻量级消息总线成本降低70%。核心代码只有37行-- publish.lua发布消息自动添加时间戳和trace_id local msg cjson.decode(ARGV[1]) msg.timestamp tonumber(ARGV[2]) msg.trace_id ARGV[3] redis.call(XADD, KEYS[1], *, data, cjson.encode(msg))但必须解决两个问题消息去重和死信队列。去重用Redis Set以{topic}:{msg_id}为keyTTL设为消息有效期死信队列用另一个Stream当消费者连续3次ACK失败自动XADD到dead_letter。这比Kafka的max.poll.interval.ms配置直观得多。对于必须用Kafka的场景重点调优三个参数linger.ms5避免小消息频繁刷盘提升吞吐enable.idempotencetrue防止Producer重试导致重复消息group.id按角色命名如fraud-group而非用随机UUID方便监控。提示永远不要在Agent代码里硬编码Kafka topic名。我用环境变量KAFKA_TOPIC_FRAUD_RESULT配合Hermes的config装饰器注入这样同一套代码可部署到测试/生产不同topic。4. 实操过程与核心环节实现手把手搭建一个采购协同系统4.1 环境准备绕过“openclaw : 无法将‘openclaw’项识别为 cmdlet”的Windows陷阱Windows用户常被这个报错卡住根本原因是PowerShell执行策略限制。不要改执行策略Set-ExecutionPolicy RemoteSigned有安全风险而是用CMD启动。具体步骤下载OpenClaw v0.8.3 Windows版非源码解压到C:\openclaw将C:\openclaw\bin加入系统PATH控制面板→系统→高级系统设置→环境变量以管理员身份打开CMD执行openclaw --version若显示0.8.3说明安装成功。若仍报错检查C:\openclaw\bin\openclaw.exe是否存在不存在则重新下载。Hermes的安装更简单但要注意Python版本必须用Python 3.103.11最佳。我试过3.9Hermes的asyncio事件循环会与某些LLM SDK冲突。安装命令pip install hermes-ai1.2.0 --extra-index-url https://pypi.org/simple/ # 验证 hermes --helpClaude Code的“中文版官网”实际是社区汉化包。官方安装命令npm install -g claude-code-cli # 启动WebUI claude-code --host 0.0.0.0 --port 3000然后访问http://localhost:3000点击右上角齿轮图标选择“简体中文”。注意CLI版不支持中文必须用WebUI。4.2 第一步角色建模实战——定义采购协同四角色我们搭建一个简化版采购系统涉及四个角色需求收集AgentDemandCollector接收销售部邮件提取采购需求供应商筛选AgentSupplierFilter根据需求匹配合格供应商比价分析AgentPriceAnalyzer获取各供应商报价计算综合得分决策建议AgentDecisionAdvisor生成采购建议报告每个角色的卡片如下以DemandCollector为例DemandCollector-v1.0卡片UID:demand-collector-v1.0输入Schema:{ type: object, properties: { email_id: {type: string}, subject: {type: string}, body: {type: string, maxLength: 5000} } }输出Schema:{ type: object, properties: { items: { type: array, items: { type: object, properties: { name: {type: string}, quantity: {type: integer, minimum: 1}, urgency: {type: string, enum: [normal, urgent, critical]} } } } } }SLA: ≤2秒内响应超时返回{error: email_parse_timeout}依赖服务: 邮件APIhttps://api.sales-mail/internal/v1/fetch注意所有Schema必须存为.json文件路径统一为./schemas/demand_collector_input.json这是后续自动化校验的基础。4.3 第二步协议设计与代码实现用Hermes实现DemandCollector关键代码from hermes import Agent, Message from pydantic import BaseModel, ValidationError import json import requests # 加载输入Schema with open(./schemas/demand_collector_input.json) as f: INPUT_SCHEMA json.load(f) class DemandInput(BaseModel): email_id: str subject: str body: str class DemandOutput(BaseModel): items: list Agent(namedemand-collector-v1.0) def demand_collector(message: Message) - Message: try: # 1. 严格校验输入 input_data DemandInput(**message.data) # 2. 调用邮件API此处模拟 email_data requests.get( fhttps://api.sales-mail/internal/v1/fetch?id{input_data.email_id}, timeout1.5 ).json() # 3. 提取需求真实项目用LLM此处简化为规则 items [] for line in email_data[body].split(\n): if 采购 in line and 台 in line: parts line.split( ) items.append({ name: parts[1], quantity: int(parts[2].replace(台, )), urgency: normal }) return Message(dataDemandOutput(itemsitems).dict()) except ValidationError as e: return Message(errorfInput validation failed: {e}) except requests.Timeout: return Message(errorEmail API timeout) except Exception as e: return Message(errorfUnexpected error: {e})这个实现体现了第二步的核心校验前置、错误分类、契约清晰。所有异常都转化为结构化错误消息下游Agent可据此决策如重试或降级。4.4 第三步通信编排——构建Kafka消息流创建三个Kafka Topic# 创建Topic假设Kafka已运行 kafka-topics.sh --create --bootstrap-server localhost:9092 \ --topic demand-input --partitions 3 --replication-factor 1 kafka-topics.sh --create --bootstrap-server localhost:9092 \ --topic supplier-output --partitions 3 --replication-factor 1 kafka-topics.sh --create --bootstrap-server localhost:9092 \ --topic price-result --partitions 3 --replication-factor 1DemandCollector的输出配置hermes_config.yamlagents: - name: demand-collector-v1.0 # ... 其他配置 output: type: kafka config: bootstrap_servers: localhost:9092 topic: demand-input # 启用幂等性 enable_idempotence: trueSupplierFilter的输入配置agents: - name: supplier-filter-v1.0 input: type: kafka config: bootstrap_servers: localhost:9092 topic: demand-input group_id: supplier-group # 自动提交offset避免重复消费 enable_auto_commit: true实测心得Kafka的auto.offset.resetearliest必须设为latest否则重启Agent会重放历史消息导致重复采购申请。这个参数在Hermes的kafka_config里配置。4.5 第四步协同验证——编写端到端测试脚本用pytest写一个测试验证从邮件输入到决策报告的全流程import pytest import json from kafka import KafkaProducer, KafkaConsumer import time def test_end_to_end_purchase_flow(): # 1. 发送模拟邮件 producer KafkaProducer(bootstrap_serverslocalhost:9092) test_email { email_id: EM2024001, subject: 紧急采购需求, body: 请采购服务器5台硬盘10块 } producer.send(demand-input, valuejson.dumps(test_email).encode()) producer.flush() # 2. 消费决策报告 consumer KafkaConsumer( decision-report, bootstrap_serverslocalhost:9092, group_idtest-group, auto_offset_resetlatest ) # 3. 等待结果最多30秒 start_time time.time() while time.time() - start_time 30: msg_pack consumer.poll(timeout_ms1000) for msgs in msg_pack.values(): for msg in msgs: result json.loads(msg.value.decode()) assert recommendation in result assert len(result[recommendation]) 0 print(✅ 端到端流程通过) return pytest.fail(❌ 30秒内未收到决策报告) if __name__ __main__: test_end_to_end_purchase_flow()这个脚本模拟真实调用链比单元测试更能暴露集成问题。我把它加入CI/CD在每次Git Push后自动运行。5. 常见问题与排查技巧实录那些文档里不会写的血泪教训5.1 “openclaw : 无法将‘openclaw’项识别为 cmdlet”的10种解法这个问题本质是Windows PATH和执行策略的组合陷阱。按优先级排序的解决方案序号解法成功率适用场景我的实测备注1用CMD而非PowerShell启动98%所有Windows版本最推荐无需改系统设置2将openclaw.exe拖到CMD窗口自动补全路径100%临时调试快速验证是否PATH问题3在PowerShell中用 C:\openclaw\bin\openclaw.exe --version95%必须用PS的场景符号强制执行4重装Python 3.10用pip install openclaw替代exe安装85%开发环境exe版有时缺DLL5检查防病毒软件是否拦截openclaw.exe70%企业电脑关闭实时防护再试6用where openclaw确认PATH是否生效90%排查PATH问题若无输出说明PATH没加对7在C:\openclaw\bin目录下直接运行openclaw.exe100%临时救急不解决根本问题8用WSL2安装Linux版OpenClaw99%WSL2已启用性能更好但需学习Linux命令9放弃OpenClaw改用HermesPython生态更稳99%新项目长期维护成本更低10重装Windows终极方案100%系统严重损坏仅当其他全失效时考虑重点提醒第4种解法中pip install openclaw安装的是源码版需pip install -r requirements.txt其中pywin32必须305否则在Windows Server上会报错。5.2 Hermes桌面版启动失败的三大元凶Hermes Desktopv1.2.0在Windows上常见启动失败日志显示Failed to connect to backend。根因分析元凶1端口冲突Hermes默认用3001端口若IIS或Skype占用了该端口就会失败。解决方案# 查看3001端口占用 netstat -ano | findstr :3001 # 杀掉进程PID为XXXX taskkill /PID XXXX /F # 或改Hermes端口在%APPDATA%\Hermes\config.json中加 {backend_port: 3002}元凶2GPU驱动不兼容Hermes Desktop的Electron框架与某些NVIDIA驱动如515.65.01冲突。表现是启动后白屏。解决方案更新到最新驱动535.98或禁用GPU加速在快捷方式目标后加--disable-gpu元凶3杀毒软件拦截360、火绒等会把Hermes的node_modules标记为可疑。解决方案临时关闭杀软或将%LOCALAPPDATA%\Programs\Hermes加入信任目录5.3 Claude Code接入DeepSeek的实操细节网上教程说“修改API Key就能接入DeepSeek”这是严重误导。DeepSeek的API与OpenAI不完全兼容主要差异差异点OpenAI标准DeepSeek API我的修复方案Endpoint/v1/chat/completions/v1/chat/completions相同无需改Model参数modelgpt-4modeldeepseek-chat必须显式指定Messages格式{role:user,content:...}同样支持但role只认user/assistantsystem角色会被忽略需合并到user contentStream响应data: {...}data: {...}相同Token计数usage.total_tokensusage.total_tokens相同关键代码修改Claude Code的api.js// 原OpenAI配置 const config { baseURL: https://api.deepseek.com/v1, headers: { Authorization: Bearer ${DEEPSEEK_API_KEY} } }; // 发送请求时强制model参数 const payload { model: deepseek-chat, // 必须加 messages: [...messages], stream: true };实测警告DeepSeek的temperature参数范围是0-2而OpenAI是0-1若直接复制OpenAI配置temperature0.7在DeepSeek上会变成过度发散。我的做法是在前端加一个“模型适配器”当选择DeepSeek时自动将temperature映射为value * 1.5上限1.5。5.4 多智能体系统一致性难题的破局点“多智能体系统一致性”是热搜词但很少有人讲透。它不是技术问题而是状态同步问题。比如采购系统中SupplierFilter查到供应商A有货PriceAnalyzer去询价时库存已售罄。传统方案是加分布式锁但会严重拖慢性能。我的破局方案是最终一致性业务补偿所有Agent操作都记录“意图”而非“结果”。SupplierFilter不返回“有货”而是返回“建议向A询价”PriceAnalyzer拿到建议后实时调用库存API若无货则触发“备选供应商”流程决策建议Agent汇总所有结果生成带置信度的报告如“供应商A置信度70%”当用户确认采购再执行最终下单此时才加锁。这个方案在某汽车零部件采购项目中将订单成功率从82%提升到99.3%且平均响应时间降低40%。核心思想是把强一致性要求从执行阶段转移到决策阶段。6. 经验总结从“能跑通”到“可运维”的最后一公里做完上面所有步骤你的多Agent系统可能已经能跑通Demo但离生产环境还有关键一公里可观测性、可审计性、可演进性。这是我踩过最多坑的领域。可观测性不是加监控而是设计监控点。我在每个Agent的入口/出口埋点agent_start_{uid}记录输入数据哈希、时间戳、trace_idagent_end_{uid}记录输出数据哈希、耗时、错误码agent_error_{uid}记录