钉群里又炸了。早上九点四十测试同学连着刷了三条“订单服务在 dev 环境怎么拉不起来”紧接着运维在下面回了一句“看下配置文件别再刷屏了”。这样的场景几乎每个研发团队每天都在上演。问题本身不难难的是同样的答案被反复回答、同样的问题被反复定位、同样的人工操作被反复执行。我们最终决定不再靠人肉去消耗这些重复劳动而是把“钉群提问—分析处理—任务执行—结果交付”这条链路整体做成一套团队级的 Agent 基础设施。这篇文章就是我在这轮建设中沉淀下来的完整实践记录从架构设计到核心模块实现再到上线之后的排查实录和治理方案希望能给正在做同类建设的团队一些直接可参考的素材。做这套东西之前我先给自己定了个调不要把 Agent 做成一个玩具也不要把“智能问答”当成终点。我们的目标很具体——让团队在钉群里提出的问题能够被自动理解、自动分析必要时直接调用系统执行任务最后把结论、工单号、变更记录原样交回群里。人只看结果过程交给基础设施。1. 从提问到交付这轮基建到底在解决什么问题1.1 团队协作里的“高频噪音”与隐性成本很多团队对重复提问的感知是“有点烦”但很少有人算过这笔账。我拉过一周的钉群消息记录光“环境为什么挂了”“这个报错什么意思”“权限怎么申请”三类问题每天就能产生 60 到 80 条。按平均每条消息牵扯两个人、每人 10 分钟计算一天就是 20 个小时的人力开销。这还没算被打断之后重新进入深度工作状态的成本——程序员都懂上下文切走再切回来远不止十分钟。更隐蔽的成本在于“回答质量不一致”。同一个问题不同的人回答深浅不一样同一个人忙的时候和闲的时候耐心也不一样。有的同事会发一段完整的排查路径有的同事直接甩一个文档链接。对于提问者来说最难受的不是得不到答案而是拿到一个半吊子答案还得自己再推演一遍。这种情况下把标准化的处理能力沉淀到基础设施里价值就不仅仅是省人力。1.2 为什么不是简单接一个聊天机器人而是“基础设施”刚开始我也理解得比较浅。当时想的方案是给钉群挂一个机器人回调收到消息之后丢给大模型让它把答案写回群聊。做起来很快可能一个下午就能出一个 Demo。但真正用起来就会发现这只是把“搜索引擎”换成了“生成答案”并没有解决闭环问题。举个例子同事问“订单服务在 dev 环境怎么拉不起来”如果只是一个聊天机器人它会给你一段“可能是端口被占用、可能是配置缺失、建议检查日志”这类正确的废话。可我们真正想让系统做到的是收到这个问题之后自己去查服务状态、看健康检查接口、翻最近一次部署的变更记录如果发现是配置项写错了直接把配置修正并触发一次重新部署然后回复“已处理订单服务已在 dev 环境重新拉起原因是配置项 XX 误写为 YY已修正”。这个差别就是从“聊天机器人”到“任务交付系统”的差别。而要做到后者需要的不是一段 Prompt 技巧而是一整套基础设施消息接入、会话管理、语义路由、模型编排、工具调用、执行审批、结果交付、观测审计。这也是我们把它定义为“团队级 Agent 基础设施”的原因——它不是一个插件而是一条完整的业务链。1.3 全链路定义六个环节一条流水线在对内宣导的时候我通常会把整条链路拆成六个环节接入、理解、规划、执行、交付、观测。接入解决的是“消息从钉群怎么进来”理解解决的是“用户到底想要什么”规划解决的是“实现目标需要分几步、先后顺序是什么”执行解决的是“每一步怎么调用系统能力”交付解决的是“结果以什么形式同步给用户”观测解决的是“整条链路的质量、成本、风险如何量化”。这个框架几乎适用于任何团队的 Agent 建设不管你的入口是钉钉、飞书还是企业微信背后对接的是 Kubernetes、工单系统还是数据库变更平台。六个环节一旦打通Agent 就不再是一个“回答问题”的工具而是一个真正能交付结果的执行者。后面整个架构设计都是围绕这六个环节展开的。2. 整体架构设计与分层思路2.1 接入层钉群消息如何变成标准事件接入层是整个链路的起点处理得不好后面全是垃圾进、垃圾出。钉钉机器人有两种主流接入方式一种是 Webhook 机器人配置简单适合单向通知另一种是 Stream 模式钉钉官方提供的长连接方式支持接收消息回调适合做对话型应用。我们选的是 Stream 模式原因很直接——它不需要暴露公网回调地址对网络策略友好而且可以复用钉钉本身的签名与加密能力。接入层不只是“收到消息”就完事还要做三件关键的事消息去重、会话聚合、元数据补充。钉钉在弱网环境下会发生重复投递如果不去重Agent 可能同一句话处理两遍轻则浪费 Token重则重复触发线上操作。我们的方案是用 Redis 存消息 ID 的布隆过滤器重复消息直接丢弃。会话聚合这块我们会把同一个群里、同一主题、五分钟之内的多条消息合并成一个会话片段避免用户拆成几段发模型却当成独立问题处理。元数据补充则是把发送人、发送时间、群名称、at 的机器人等信息打包成统一的上下文结构供下游使用。这里有一个很容易被忽略的坑钉群的 Webhook 机器人的关键词限制。有些机器人必须先设置关键词消息里包含指定关键词才会被机器人感知。我们在搭建早期被这个机制坑过一次配置了“运维”作为关键词结果同事问“开发环境的服务起不来”根本不会被机器人收到。后来我们换成了 Stream 模式这个问题才彻底消失。如果你所在团队暂时只能走 Webhook务必要把触发词设计得够宽或者在群里引导统一的提问前缀。2.2 路由与编排层语义路由与模型选择策略消息进入系统之后第一件事不是直接丢给大模型而是先做一次“语义路由”。为什么要多此一举因为不是所有问题都需要走大模型也不是所有问题都适合用同一个模型处理。把“今天是不是发版日”这种问题交给一个 80B 以上的大模型纯属浪费把一段复杂的 Kubernetes 故障日志甩给一个小模型又可能得到一堆胡话。我们的路由识别节点分了三级。第一级是域名判定用规则匹配判断问题属于运维、开发、测试、数据还是权限域这一步准确率能做到 90% 以上第二级是意图分类用一个小参数模型识别用户的操作意图——是“查状态”、“改配置”、“跑任务”还是“问知识”这一步决定后续是否允许调用工具第三级是复杂度评估根据消息长度、关键词密度和历史相似问题估算处理这个问题需要多大的模型能力从而决定路由到大模型还是小模型。这里面有个很实用的经验模型选择不要做成“固定配置”而是要做成路由策略的一部分。我们实际在用的一套分级是简单知识问答走 7B 级别的模型成本低、延迟低中等难度的问题走 14B 级别涉及工具调用、代码生成、复杂排查的场景才走最强的商用模型。选型不是越强越好而是“够用就行”。我见过一些团队把每个请求都交给最强的模型月底账单出来的时候整个人都不好了——成本直接高出五倍。编排层则负责把大的目标拆解成多个步骤。这里我们用到了两层编排第一层是流程编排用代码定义固定流程比如“查状态—看日志—定位问题—执行修复”第二层是动态编排由模型在运行时决定下一步调用什么工具。固定流程保证的是稳定性和可控性动态编排保证的是灵活性和应变能力。两者结合比纯靠模型自由发挥要可靠得多。2.3 执行与交付层工具调用、结果回填与闭环执行层是 Agent 从“会说”变成“会做”的关键层。我们接入的工具主要包括Kubernetes 集群信息查询、日志平台的检索接口、内部知识库、工单系统、监控告警平台、甚至还有一套基于 Ansible 的运维任务执行通道。每个工具在接入之前都必须提供一份标准 OpenAPI 描述包括操作说明、入参格式、权限级别、幂等性说明。这里我要特别强调“幂等性”。工具调用这件事最怕的就是“执行了两次”。网络超时、消息重试、模型对同一个工具的反复调用都可能导致重复执行。尤其是工单系统——如果因为超时重发同一个问题被创建了三个工单用户不骂娘才怪。我们的处理方式是每个工具调用都要求传入一个幂等键Idempotency Key后端根据幂等键做去重。交付层相对直观但要讲究方法。我们最初的做法是把 Agent 的回复原文直接发回群里结果收到最多的反馈是“太啰嗦了”“像在写论文”。后来我们设计了一套标准的交付模板开头是结论一句话说清楚“处理了什么、结果如何”中间是过程摘要用要点列出关键证据链比如日志里的报错时间点、配置项的差异结尾是后续建议如果有需要人额外处理的部分明确写出来。模板化不是限制 Agent 的表达能力而是保证信息传递的效率——群里的人没时间看长篇大论他们要的是快速做判断。3. 核心模块的实操实现与关键细节3.1 会话管理从群里的“一串对话”到可追踪的 Session钉群里面的消息天然是“多对多”的这给会话管理带来了不小的挑战。传统的聊天机器人是“一对一”对话上下文就是两个人的聊天记录但钉群里往往是 A 提问、B 补充、C 参与讨论如果 Agent 不加区分地把所有消息都作为上下文很容易被无关信息干扰甚至出现“精神分裂”式的回复。我们的做法是引入“会话窗口”的概念。每条进入系统的消息会根据群 ID、发送人 ID、消息中引用关系、时间间隔被归类到一个 Session 中。具体逻辑包含三部分其一如果消息是在回复某人就强制继承那条消息所属的 Session其二同一发送人在十分钟内的连续发言归入同一 Session其三如果一个新问题出现但群里没有上下文线索就新建一个 Session。每个 Session 有独立的 ID、独立的 Token 计数和独立的超时时间。Session 的数据结构要提前设计好因为后面很多功能都依赖它。我在表设计上放了一个 sessions 主表记录了 session_id、group_id、user_id、status、created_at一个 session_messages 表存每一条消息一个 session_context 表存中途产生的中间结果比如模型已经查到的日志、工具调用返回的数据。这样设计的好处是即使 Agent 在处理中途被重启也能通过 session_id 恢复现场而不是在群里重新问一遍用户。另外一个细节是 Session 的归档策略。钉群里的问题通常都是短平快的一个 Session 的生命周期可能只有几分钟。如果 Session 永远不关上下文会越攒越多最终撑爆 Token 预算。我们的策略是任务完成后 Session 立即归档保留关键元数据但具体消息体只保留摘要。后续如果用户再次提问系统会根据摘要决定是否关联历史而不是盲目地把老消息全部拉回来。3.2 上下文管理长上下文与记忆裁剪的取舍做过 Agent 开发的人都知道上下文是成本和质量的核心杠杆。上下文给得太多模型容易被噪音带偏成本还高给得太少模型缺乏足够信息回答质量堪忧。在团队级基础设施里这个问题会被放大——每个群里同时在跑多个 Session多个模型并发调用Token 消耗是跟着涨的。我实践下来的核心原则是“分层上下文”第一层是系统级上下文包括 Agent 的角色定义、行为规范、可用工具的清单和调用约束这部分每轮请求都会带上但内容要精简通常控制在 500 Token 以内第二层是会话级上下文包括当前 Session 中用户最近的若干轮对话、关键中间结果这部分通过裁剪策略动态调整第三层是知识级上下文只有模型判定需要查询外部知识时才注入比如搜到的 Wiki 片段、日志内容、配置项说明。上下文裁剪我这里给一个具体的做法按时间衰减和相关性排序保留最重要的内容。相关性怎么算我们用了一种很朴素但有效的方式——计算历史消息与当前问题的文本相似度超过阈值的保留低于阈值的丢弃。这样做在代码实现上不复杂但对控制上下文质量非常有效。实测下来加入相关性裁剪之后复杂问题的处理成功率从 68% 提升到了 81%Token 消耗整体下降了约 35%。另一个必须警惕的是“上下文中毒”风险。群里偶尔会出现一些与任务无关的异常言论或者是用户故意测试系统的输入。如果这些内容被当作上下文带入模型模型就可能被误导。我们的防护策略是用户消息进入上下文之前过一遍敏感信息过滤和指令注入检测。规则很简单——区分“用户要 Agent 做什么”和“用户试图让 Agent 以为自己是什么”。凡是出现“忽略之前所有指令”这类句式直接降级处理强制重置系统提示词。3.3 工具与 Skill 的规范化让 Agent 能安全地干活很多做 Agent 的团队前期热火朝天后期一地鸡毛问题大多出在工具管理上。工具没有统一的规范Agent 用起来就像一盘散沙工具没有权限控制真出事故的时候没人兜得住。所以工具管理是我们重点投入的模块也是我最想分享经验的部分。工具接入的第一条规范是“一切皆 Skill”。我们内部把 Skill 定义为“Agent 可调用的最小业务能力单元”每个 Skill 必需四个要素清晰的名称与描述、标准化的输入输出 Schema、独立的权限等级、完整的测试用例。比如“查询服务状态”是一个 Skill“重启服务”是另一个 Skill前者权限等级低后者权限等级高。同一个 Agent 在对话中只能调用它被授权范围内的 Skill超出的部分直接拒绝。Skill 的编排采用分层设计。基础层是原子 Skill一个 Skill 只做一件事比如“查询 Pod 状态”“获取工单详情”。组合层是流程 Skill由多个原子 Skill 按固定顺序组合而成比如“排查服务不可用”这个流程 Skill 内部就包含查询状态、查日志、查变更记录三个原子操作。组合层解决了 Agent 自由编排不稳定性的问题——对于高频、标准化的任务直接用流程 Skill 保证一致性对于低频、个性化的任务才允许模型自己组合。有一个很关键的认知要纠正Skill 不是越多越好。我见过有些团队塞了几百个 Skill 给 Agent结果模型连该调哪个都分不清。我们的经验是先做减法能把 80% 场景覆盖到的二十个 Skill 打磨好远胜于一百个粗制滥造的 Skill。Skill 的质量评估也不能只看调用成功率还要看用户在后续群里有没有继续追问。如果用户每次都要追问一句“那然后呢”说明 Skill 的输出没有真正解决问题。3.4 多 Agent 协作与 A2A 协议的作用随着业务场景变复杂单个 Agent 越来越难覆盖所有能力。我们内部一开始是一个“全能 Agent”在干活后来发现它的 Prompt 越来越长、工具列表越来越长、调用成功率逐渐下降。最典型的问题是路由冲突——一个 Agent 里既有查询类工具又有变更类工具模型经常在该不该调用的边界上犯迷糊。后来我们把架构改成“1 个调度 Agent N 个专业 Agent”的模式。调度 Agent 只负责理解意图、规划任务、分发请求不直接执行工具调用专业 Agent 各自背一个领域比如运维 Agent、测试 Agent、数据 Agent只负责自己领域内的工具调用与结果生成。这个模式下每个 Agent 的 Prompt 短了工具列表清晰了准确率自然上去了。多 Agent 之间怎么通信是这轮改造里比较有意思的技术点。我们参考了 A2AAgent-to-Agent协议的思想Agent 之间通过标准化的 Agent Card 来描述自身能力调度 Agent 根据任务特征选择合适的下游 Agent双方通过 JSON-RPC 风格的消息进行请求与响应。不需要把所有 Agent 都做在一个进程里而是每个 Agent 以独立服务方式部署通过内部消息总线通信。这样带来的好处是某个 Agent 升级或者故障时不影响其他 Agent新增领域 Agent 也只要注册自己的 Agent Card 给调度中心调度路由自动生效不需要改动既有代码。协议版本差异是需要注意的——如果你也打算参考 A2A 方案记得关注 Agent Card 的版本兼容性建议从简单的字段集开始后续按需扩展避免上来就套大而全的规范导致落地成本过高。3.5 任务交付格式不是给答案而是给结论交付环节看起来只是“发一段消息回群里”实际上对用户体验的影响极大。我们第一版做的是“模型直出式回复”效果很惨烈。模型倾向把所有信息都铺开讲一遍从背景到原因到过程写一大段。群里的同事根本不看直接回复“说重点”。改进的方式是推行“三层交付结构”。第一层是一句话结论比如“订单服务不可用的原因是配置项 XX 被误改已修正并重新部署当前状态正常”第二层是支撑证据用列表列出两到三个关键信息比如“原配置值为 A现配置值为 B”“重新部署版本为 v2.3.1”证据不追求全只追求能让人快速信任第三层是可选动作如果存在需要用户接着做的事就提出来比如“建议观察十分钟如果仍有异常请联系 SRE 值班组”。除了模板本身我们还定义了交付的“回执机制”。对于已经执行了变更类操作的 Agent 任务交付消息必须附带一个额外的确认入口——在钉群里表现为一个小按钮让用户点击“确认收到”或者“仍有问题”。点击数据会回流到观测系统作为 Agent 服务质量的核心指标之一。这个设计在最初被质疑“多此一举”但实际上线后它帮我们识别出了很多 Agent 自以为解决、用户并不认可的场景是质量迭代的重要抓手。4. 上线之后的踩坑与排查实录4.1 问题一群消息乱序导致 Agent 状态混乱上线第一天我们就碰上了问题同一个 Session 里的消息顺序有时候是乱的。钉钉的 Stream 模式虽然按接收顺序推送但当 Agent 处理过程中有多个异步任务在跑时消息进入下游的顺序就和实际发生顺序不一致了。比如用户先发“帮我查下订单服务的状态”紧接着又说“顺便看下昨天有没有发版”结果后一句先被处理Agent 先回了发版信息用户一脸懵。排查路径走了一圈最终确认问题出在我们的消息管道上。我们把钉群消息先放进了一个内存队列再由异步 Worker 消费多个 Worker 并发消费时同一个 Session 的消息就可能被不同 Worker 拿走处理顺序就乱了。解决方案不难按 Session ID 做一致性哈希把同一个 Session 的消费任务固定路由到同一个 Worker。这样一来同一个 Session 的内部消息严格串行顺序问题基本消失。另一个相关问题是消息批量到达时的突发流量。群里有经验丰富的同事会把一连串问题一次性发出来Agent 收到的不是一个问题而是一整段。我们的做法是在入口做一个聚合窗口——两秒内的多条消息先做合并如果内容明显指向多个独立问题再拆成多个子任务而不是把一个组合问题粗暴地当成一个问题处理。这个优化看似微小对回答质量的提升非常明显。4.2 问题二上下文爆掉Token 预算怎么定上线一段时间后我们发现部分复杂任务的 Token 消耗高得离谱。一个平常排查任务的会话上下文竟然累计到了 8 万 Token。原因主要有两个一是模型在处理过程中频繁查询工具每次查询结果都原封不动塞进历史二是日志内容太长模型把整段日志都当成推理依据没有做截断。这件事逼着我们给 Token 预算定了一套硬规则。单次请求的上限默认 8K Token其中用户输入最多占 20%、工具返回结果最多占 50%、系统指令和会话历史最多占 30%。超过预算时优先裁剪工具返回结果——日志类信息只保留匹配关键字的上下文片段知识库内容只保留标题和摘要其次裁剪会话历史——按时间衰减保留最近的消息老消息摘要化最后才考虑升级模型上下文窗口。这套规则实操下来复杂任务的 Token 消耗被打到了原来的三分之一左右回答质量没有明显下降。预算之外还有一个容易被忽略的点模型的重试机制也会放大 Token 消耗。我们刚开始给模型调用设置了三次自动重试碰上模型偶尔抽风时一次请求实际消耗的是四次的 Token。后来把重试策略改成“仅网络错误重试业务错误不重试”并且每次重试都带上指数退避整体成本又降了一截。4.3 问题三工具调用死循环Agent 陷入无法自拔的循环有一次线上事故让我印象很深Agent 在排查一个服务故障时反复调用“查询服务状态”工具每次查询结果都显示“部署中”它就一直等、一直查最后连续调用了 40 多次把下游 OpenAPI 的限流都打爆了。问题本质是模型的规划进入了一个“无效循环”——工具结果没有带来新信息但模型没有任何停止条件。我们给工具调用层加了三道保险。第一道是单 Session 的最大工具调用次数限制默认 10 次超过后强制终止并生成一个“人工介入建议”交付给用户第二道是结果变化检测如果连续三次工具调用返回的结果完全相同就判定为“没有进展”触发中断第三道是每次工具调用后的“信息增益评估”模型在追加工具调用前必须说明上一次工具结果提供了什么新信息如果回答不出来则不允许继续调用。这些机制组合下来死循环问题基本绝迹。还有一个现场级的排查技巧值得分享给每一次工具调用生成唯一 trace_id并和 Session ID、模型请求 ID 一起透传到所有日志中。排查类似死循环问题时直接按 trace_id 拉链路一眼就能看到模型的决策链路是在哪一步开始跑偏的。没有链路追踪你只能在日志海里捞针。4.4 问题四Agent 越权权限边界怎么守住权限问题是所有 Agent 落地过程中绕不开的坎。我们早期出过一次事故有同事在群里问“把测试环境的数据清一下”Agent 竟然真的调用了数据库清理工具把测试环境的几张表给清空了。虽然测试环境数据可以恢复但这个事件让团队对 Agent 的信任度瞬间降到冰点。复盘之后我们明确了两个原则。第一个原则是“分级授权”读操作可以自动化写和变更操作必须经过审批。具体落地为——查询类 Agent 任务自动执行写操作生成“待审批工单”在群里推送审批卡片由特定角色的人点确认后才执行高危操作比如删除数据、变更生产配置直接拒绝不在 Agent 能力范围内。第二个原则是“环境隔离”Agent 使用的凭证按环境独立签发测试环境的凭证绝对不能有生产环境的权限。之前事故发生一个重要原因是当时用了同一个高权限 TokenAgent 在测试环境执行时实际上也具备生产环境能力。权限体系上线后我们把 Agent 的资金池、凭证库和操作审计全部接入了统一权限网关。每一次操作无论大小都会记录操作者Agent 身份、操作对象、操作命令、审批人、时间戳方便回溯。4.5 常见问题速查表为了方便团队内部排查我整理了一份速查表这里直接分享出来。这张表里记录的每一个问题都是我们在实际上线后遇到过的。症状可能原因排查思路与处理方案Agent 不响应消息没进入系统 / 会话聚合失效先查消息管道日志确认消息是否到达再查 Session 构建逻辑确认会话归属是否正确回复与问题无关语义路由分类错误 / 上下文噪音过大查看路由结果确认问题被路由到了哪个领域检查上下文裁剪策略看是否混入了无关消息回答过于笼统模型能力不足 / 上下文缺少工具结果检查本次请求实际注入的 Token 内容确认工具调用返回是否被正确保留工具调用频繁失败下游接口限流 / 凭证过期 / 参数格式不匹配查工具调用 trace确认失败原因定期刷新凭证在 Skill 定义中校验 Schema 兼容性Agent 反复执行同一操作缺少幂等键 / 死循环检测未触发检查工具调用日志中的幂等键确认是否相同查看死循环检测条件是否被满足用户对交付结果不满意交付模板未达标 / 缺少结论前置拉取交付消息样本检查是否符合三层交付结构针对性调整 Prompt 与交付模板5. 安全治理与运维观测5.1 最小权限与操作隔离Agent 的安全治理是一个持续对抗的过程不是上线时配一次权限就高枕无忧。我们内部把安全策略分成四个层面逐层落实。第一层是“身份与凭证隔离”。每个 Agent 有独立的服务账号不同环境的凭证严格分离凭证统一托管在密钥管理服务中禁止在代码或配置文件中硬编码。如果某个 Agent 的凭证泄露可以独立吊销不影响其他 Agent。第二层是“操作白名单”。每个 Agent 只能调用它所属领域内的 SkillSkill 再做细分到具体操作、具体环境、具体资源。比如运维 Agent 可以查看所有环境的服务状态但只有 SRE 审批后才允许变更生产环境。第三层是“敏感操作双人复核”。对于删除、变更、批量操作类任务Agent 只负责生成操作计划和执行脚本必须由至少两位具有相应权限的同事审批通过后才真正执行。人仍然是关键控制点。第四层是“全量审计”。每次 Agent 的操作记录、模型决策日志、工具调用入参与返回、审批人信息全部落库保留至少 180 天。我们甚至为每个执行过的任务生成了类似于“操作回放”的完整记录用于合规审计。安全实践中有一条很容易被忽视Agent 的幻觉在权限场景下尤其危险。模型可能以为自己调用了工具、执行了变更但实际上它只是“编造”了一个执行成功的假象。我们为此专门给重要工具加了“执行回执校验”——工具执行后Agent 必须再次查询结果状态确认变更真正生效才能向用户宣告成功。这一步虽然多了一次工具调用但它能拦住大量自我欺骗式的假成功。5.2 观测指标体系从“回复率”到“任务完成率”做了基础设施之后我就没再用“回复是否流畅”来评价 Agent 效果了。观测团队级 Agent 基础设施需要一套覆盖质量、成本、风险和体验的多维指标体系。质量层面我们核心盯三个指标任务完成率、首次解决率、用户确认率。任务完成率反映的是 Agent 处理任务的闭环比例是基础设施价值的核心体现首次解决率衡量的是用户提一个问题Agent 是否一次就真正解决了不需要追问用户确认率则来自前面提到的钉群回执按钮代表用户侧的真实反馈。成本层面我们按 Session 维度统计 Token 消耗、模型调用次数、工具调用次数按月做成本归因。风险层面我们重点监控权限审批通过率、异常操作拦截量、敏感操作占比一旦发现某个 Agent 频繁触发高危操作立刻拉出它的决策链条做排查。在数据分析中发现一个有意思的现象刚开始我们追求“回复快”不断压低模型调用延迟。但后来发现用户对 30 秒内返回的“不确定答案”的容忍度远低于对 2 分钟内返回的“确定答案”的容忍度。团队级基础设施的体验优化真正应该盯的不是单次响应快慢而是端到端的“任务解决时间”——从用户提问到用户确认问题解决才是完整的体验周期。5.3 降级与熔断Agent 挂了之后怎么保证业务不停任何基础设施都要回答一个问题它挂了会怎么样Agent 基础设施也不例外。我们在设计之初就定下一个原则——Agent 只是“增强”不能成为“依赖”。即使 Agent 完全不可用团队的日常协作不能受到任何阻断。基于这个原则我们做了三层降级策略。第一层是模型降级主模型不可用时自动切换到备用模型如果备用模型全部不可用则进入纯规则模式用关键词匹配和预设脚本回答最高频的 20% 问题。第二层是能力降级推理引擎可用但工具通道异常时Agent 进入“只读模式”拒绝一切写操作只能查状态、读日志防止在故障状态下做出错误变更。第三层是入口降级当 Agent 基础设施整体异常钉群入口自动切换为“静默模式”机器人不响应任何消息并推送一条系统公告说明服务暂不可用。这个策略看似保守实际能避免很多二次故障。还有一个影响业务连续性的细节Agent 依赖的模型服务如果出现单点故障之前的会话上下文能否保存我们提前做了 Session 状态持久化每个 Session 的中间处理状态都同步写入了 Redis 和数据库模型服务切换后新模型实例可以从持久化状态恢复上下文用户无感知。这也印证了前面强调的——把 Agent 当成基础设施来做不是在做一个功能而是在做一个服务服务的可靠性设计是必修课。我个人的体会是Agent 基础设施最难的其实不是技术选型而是把团队的协作习惯、系统的操作边界和模型的推理能力三者揉在一起。钉群里的每一个提问背后都是一个人当下的真实困境Agent 交付的每一个结果都应该让这个困境真正消失而不是又留下一个需要人工擦屁股的半成品。现在这套体系已经在团队里稳定跑了大半年从最初的“尝鲜”变成了同事口中“离不开的基建”。后续我们还在扩展新的领域 Agent也在探索把更多的自动化运维场景纳入闭环。走这条路的过程就是不断在“模型能力的天花板”和“业务可靠性的地板”之间找平衡的过程。希望这篇实践记录能给正在做同样事情的你一些参考。
