过去半年我先后参与了几家企业的 AI Native 内部复盘。一个现象让我印象很深会议室里展示的 Agent 数量越来越多但工单系统的重复率几乎纹丝不动。同一个报错、同一个配置项、同一类数据异常上午是人在排查下午是 Agent 在答复第二天换一拨人接着查。团队把这种现象概括得很准确人和 Agent 都在解决同一个问题但问题本身从来没被解决掉。这让我重新校正了对 AI Native 的理解。AI Native 不是把 Agent 当成一个回答速度更快的新客服而是要把问题终结在发生之前或者至少终结在同一类问题的反复出现上。只要一类问题还需要人或者 Agent 反复处理就说明系统还停留在“用 AI 做补救”的阶段距离 Native 还有一大截。1. 先看清病灶Agent 上线后问题总量没降反升的企业长什么样1.1 从“AI 助手”到“AI 员工”问题只是换了回答者很多企业在第一阶段上了一批“AI 助手”客服机器人、研发 Copilot、运营问答机器人。用户提问Agent 回答。用户拿到答案问题从“待办”变成“已完成”所有人松了一口气。但实际上工单系统里解决问题的方式几乎没变——只是从人敲键盘变成了 Agent 吐答案。这背后是一种很普遍的错觉只要问题被回答得足够快就算被解决。但被“回答掉”的问题不等于被“解决掉”的问题。Agent 能生成一段排查步骤不代表底层配置变更了能写一段修复脚本不代表它被审批和执行了能告诉业务同学“这是历史遗留问题”不代表有任何人去推动历史遗留的根因治理。于是出现了一种我称之为“解决方案层繁荣、根因层寂静”的状态Agent 看起来能回答一切但问题产生的源头一动不动。1.2 “反复解决”的三种典型画面画面一告警噪音。监控平台每天抛出几百条同类型告警Agent 会逐条分析给出“和昨天一样的结论预计是缓存未命中导致”。结论没错但缓存策略没有改第二天同样的告警继续来。人和 Agent 都被耗在“分析同一条告警”上。画面二客服热线。用户报告“账单对不上”。Agent 查到是一笔延迟入账给了安抚话术。用户满意走了。可支付对账脚本的缺陷没修下个月同一场景再次出现。客服和 Agent 再次重复同样的查询、同样的解释。画面三研发答疑。开发同学在内部论坛提问“为什么构建又失败”Agent 回复了三个可能性。但最根本的原因——某个镜像 tag 总是被覆盖——没人动手改流水线于是这个问题每周都变成新的“知识库条目”。这三个画面有一个共同结构每次都解决“当前症状”每次都没有关闭“问题类别”。所以工具越多、Agent 越多团队越忙。1.3 本质原因只在解决“问题实例”没人消灭“问题类别”借用软件工程里“缺陷实例 vs 缺陷类”的概念一个缺陷类可以派生出成千上万个实例。传统质量体系会要求修复后补回归测试、更新根因分析目的就是关闭整个缺陷类。AI Native 落地时恰恰最容易忽略这一步。很多团队把精力放在提高 Agent 的单次答对率、降低单次响应时长却忘了问一句这个问题为什么还会出现第二次如果每次出现都做一次“一次性处理”那么无论执行主体是人还是 Agent企业的运行方式依然是纯粹的事件驱动只是驱动它的引擎从人被换成了大模型。这不叫 AI Native叫“AI 外包的外包”。2. 为什么答案越多问题越顽固上下文、归因、验收三处断裂这一节要拆根因。AI Native 的问题治理链路通常包括感知监控/工单→ 上下文检索知识/历史→ 诊断与归因大模型推理→ 修复执行工具调用/人工→ 验证测试/复盘。理想情况下这条链路应该闭环但在我观察的企业里链路几乎都是断的。2.1 上下文断裂Agent 有会话记忆但组织没有沉淀记忆当前很多 Agent 架构里“记忆”是个热词。会话记忆、向量记忆、长期记忆大家都在做。但企业层面真正需要的不是某一台 Agent 记住上次和某个用户说了什么而是当一类问题再次出现时所有历史处置经验可以被同一条链路复用。遗憾的是多数企业的记忆是碎片化的A 团队的知识在文档站点B 团队的脚本在代码仓库C 团队的结论散落在即时通讯群里。Agent 每次检索能拿到的上下文非常有限。更麻烦的是当一位资深工程师“凭经验”处理完一个疑难问题时这段经验如果不被结构化回写Agent 下次依然要从零开始推理。所以要打破上下文断裂必须把“经验回写”设计成 Agent 工作流中的强制步骤而不是看个人的主动性。这比单纯给 Agent 加内存容量重要得多。2.2 归因断裂Agent 提供答案但没把答案回填到根因第二个断裂更隐蔽。Agent 特别擅长“回答问题”但很少自动把“答案”转换成“根因修复动作”。例如Agent 分析出一个线上故障是因为某条配置被误改它给出“请回滚”的建议后任务就结束了。配置的变更审批、变更记录、负责人同步这些后续动作往往还是靠人手工去追。为什么会有这个断裂因为大多数 Agent 是基于“对话即服务”的思路设计的目标是让用户满意不是让系统变好。一旦把 KPI 设定成“平均回答时长”Agent 的优化方向就是更快给结论而不是驱动后续动作闭环。归因断裂的本质是价值导向的偏差。必须有一个不属于任何单一业务线的角色或机制比如稳定性小组或“问题终结者”去承接 Agent 给出的归因推动根因修补。否则 Agent 越多归因越多落地的修复却寥寥无几。2.3 验收断裂修复从未被验证重复也就理所当然第三个断裂和工程文化有关。研发团队都知道一个原则没有测试的代码变更算不算完成标准答案是不算。但在 AI Native 的运维、客服和业务运营场景里这条原则经常被忘得一干二净。Agent 改了一条告警阈值、调了一个参数、更新了一段知识库怎么证明这个问题不会再犯大多数团队没有对应的回归验证。于是同一个问题在下一轮数据变化后“复现”看起来像是偶发其实是验收机制缺失。避免这个问题需要把验证动作和问题类别绑定每个 Agent 修复动作都应该能关联到一组自动化测试至少是回放历史工单确认同类输入不再触发同类异常。再往下才是评估集和评测体系。这也是为什么“Agent 测试”“Agent 评估”会变成 AI Native 落地里的高频词——因为大家终于发现没有验收的 Agent 能力不过是另一种形式的技术债。3. 终结问题类别而不是终结问题实例四个必须补上的工程组件针对三处断裂我建议企业在技术层面补四个组件而不是急着换更强的基座模型。很多团队以为 Agent 能力不行其实是“容器”不行——问题没地方沉淀能力没地方挂载行为没地方验证。3.1 技能库把经验变成可调用、可组合的原子能力“Agent 技能”是最近特别受关注的一个概念但很多团队只把它理解为“给 Agent 多装几个工具”。其实两者有本质区别工具解决“能做什么”技能解决“该怎么做才符合组织沉淀的最佳实践”。比如一个“数据库慢查询诊断”技能它不只包含查询数据的 SQL还包含一套处置流程先看慢查询统计再抓执行计划然后对比历史基线最后给出优化建议。每一步都可能调用工具但技能本身是经验的具象化。把资深 DBA 的排查路径转成技能相当于把老师傅的脑子“复制”给了每个 Agent。这里给一个简单的技能注册表示例供参考# 技能注册项示例 - name: db_slow_query_diagnosis version: 1.2 owner_team: platform-dba trigger: type: pattern match: [慢查询, database latency, 执行计划异常] actions: - query: pg_stat_statements - collect_explain: true - compare_baseline: last_7d verification: - regression_case: dba_slow_query_20250501 - expected: query_plan_change_within_baseline技能库的另一个价值是可组合。一个复杂问题往往需要多个技能串起来先“日志检索”再“根因推断”最后“配置回滚”。如果每个 Agent 都各自写 prompt 完成这些事迟早会失控把技能做成标准模块就可以像搭乐高一样编排。3.2 组织记忆层从对话记录中提炼长期记忆要用好 Agent光有技能还不够还得让它读得懂企业的历史。组织记忆层我建议至少包含三类数据事件档案每一次故障、告警、工单的完整闭环记录包括根因、处置步骤、修复产物。决策记录为什么当时选了方案 A 而不是方案 B。这类知识通常散落在人脑和文档里对 Agent 的推理质量影响极大。负面清单哪些账号不能动、哪些目录不能写、哪些操作必须双人复核。这是 Agent 安全边界的一部分也是一种记忆。组织记忆层不一定非得用复杂的图数据库。先从一个简单的向量知识库开始把历史工单、复盘文档、变更记录同步进去已经能显著提升 Agent 回答的“企业味”。关键是同步机制和更新责任而不是模型和存储。很多企业买了一个向量库就不管了数据三个月没更新那 Agent 再聪明也是靠过期信息做题。3.3 回归验证与评估集给修复配一条安全带这个组件最容易被低估。我见过太多团队花大量精力调 prompt却不肯花时间建评估集。实际上对 AI Native 工程来说评估集就是“测试用例”Agent 每次升级模型、换提示词、改技能都应该先跑一遍回归。评估集怎么建不要一上来就找公开数据集最有效的是把过去半年“同类型问题”的真实工单和历史故障抽出来按问题类别分组每组配上标准回答和验证动作。比如“配置类问题”30 条、“数据异常类问题”20 条、“网络抖动类问题”15 条。先保证重放这些历史案例时Agent 的解法能达到资深专家的水平然后再用人工标注的新案例扩集。另外验证不只发生在评测环境。生产环境里每个 Agent 的修复动作都应该自动触发一条“验证任务”这条告警在下一个小时还出现吗参数变更后容量曲线回落到预期区间了吗只要验证任务未通过就不允许这个 Agent 把同类问题标记为已解决。这一步一旦落地“人和 Agent 反复解决同一类问题”的现象会立刻少一半。3.4 可控执行环境让 Agent 有权限但不越界前面讲了不少“自动化”这里必须泼一盆冷水没有边界的自动化就是事故加速器。Agent 安全不是一句口号而是落到执行环境上。所谓 Harness可以理解成 Agent 的脚手架和运行时容器它规定 Agent 能调哪些工具、能访问哪些系统、动作是否需要审批、日志如何留存。Harness 和 Agent 的区别打个比方Agent 是司机Harness 是车上的刹车、安全带、交通规则和 GPS 记录仪。司机技术再好也不能没有刹车。安全边界至少要有这四层最小权限默认只读需要写操作时必须显式授权。变更审批生产变更必须关联审批单敏感命令双人复核。沙箱隔离代码执行类技能在隔离沙箱里跑不能直接接触生产数据。全量审计Agent 每次动作都要留痕方便复盘和追责。没有这套东西技能库和记忆层建设得越好风险越大——因为 Agent 有了更强的能力也就有了更大的破坏半径。4. 从技术选型到 Agent 架构真正拉开差距的是问题分类能力技术组件想清楚后很多团队会卡在下一关用什么框架、怎么搭架构。我的建议是先别急着选框架先把你要解决的问题分类。4.1 先把问题分好类再决定用哪种 Agent 架构我把企业里常见问题粗略分成四个象限象限问题的已知度最佳 Agent 形态典型场景第一象限已知问题已知解法单 Agent 技能库运维告警、标准工单、权限申请第二象限已知问题解法不确定单 Agent 检索增强 多步推理研发疑难杂症、客服复杂投诉第三象限问题不确定目标已知多 Agent 协同 工具调用数据异常排查、根因分析第四象限问题未知目标模糊人在回路 探索型 Agent新业务模式探索、架构治理大多数企业的重复性困扰集中在第一、二象限这是最容易先把“问题类别”关闭掉的部分。第三象限适合引入多 Agent 做横向排查第四象限暂时不要谈自动化先把 Agent 定位成“放大人类分析师思路”的工具。4.2 LangChain、Dify、CrewAI 与自研 Harness选型不是追新关于框架经常有人问LangChain 好还是 Dify 好CrewAI 值不值得学我的回答是先看你的团队有没有能力维护抽象层。方案抽象层级优点适合谁LangChain代码级框架灵活组件丰富研发能力强、需要深度定制的团队Dify平台化产品上手快自带 UI/工作流业务和研发混合团队快速验证CrewAI多 Agent 协作框架便于定义角色和协作已经有清晰 Agent 分工的团队自研 Harness完全可控最能贴合内部系统规模大、问题类别稳定、有平台团队我的态度是如果企业还处在探索期选 LangChain 或 Dify 都行重点是把数据接进来跑通如果已经稳定处理大量同类问题必须考虑自研或深度定制 Harness。因为问题的所有权、记忆的回写、技能的注册、安全的边界都会和公司内部系统深度耦合通用框架很难满足全链路要求。4.3 主从、流水线、编排器三种模式的适用场景最后讲常见的 Agent 架构模式。我不太建议一上来就搭一个“超级 Agent”什么都让它管。更务实的是按问题场景选择拓扑流水线模式按固定步骤执行适合第一象限的标准流程例如“告警接入 → 日志检索 → 根因推断 → 生成工单 → 回填验证”。主从模式主 Agent 负责任务分解多个子 Agent 并行处理适合第三象限的根因排查。编排器模式一个编排层根据问题类型动态选择技能和模型适合第二象限的相对复杂场景。真实落地时三种模式往往是混着用的。关键在于“问题分类”这个动作要足够好——如果分类错了再好的架构也只是在错误的方向上加速。这也是为什么技能库和记忆层是最该先做的基础设施因为它们是“问题分类”的质量保障。5. 组织机制和度量指标不换技术栈再先进也白搭技术框架搭好了如果组织机制还停留在“有人解决就算完”很快会打回原形。这一节聊聊流程、指标和人的分工。5.1 把“解决一个问题”变成“关闭一个问题类别”流程上我建议引入一个“问题类关闭”的定义。一个问题要算真正关闭必须同时满足四个条件根因被定位并且回填到根因库或知识库。修复动作已触发是代码变更、配置变更或者流程变更而不是一次性口头处理。对应的回归验证已通过同类输入不会再触发同类异常。负责团队已经确认问题的“责任空间”并在后续迭代里持续关注。这有点像软件工程里的“缺陷关闭标准”只是把维度延伸到了 AI Native 的整个运行体系。每个 Agent 在触发修复后都应该输出一张“是否满足关闭条件”的自检清单不满足就把它转给人工接续处置。5.2 度量指标别再单看 MTTR要看同类问题复发率很多企业看 Agent 的指标还是老话平均修复时间MTTR降了多少。MTTR 当然重要但它只衡量“一次性问题处理速度”完全衡量不了“问题类别有没有被终结”。我建议至少同时看三组指标同类问题复发率同一问题类别在 30 天内再次出现的比例。自动化关闭率在“问题终结”的所有条件中由 Agent 自动完成全部步骤的比例。根因回填率Agent 处理完的问题中有多少比例真正更新了根因库或知识库。如果复现率不降MTTR 再漂亮也只能说明团队在处理重复劳动上更熟练了。别用效率指标掩盖根因治理的缺失。5.3 人的分工从“重复劳动”转向“例外管理与经验编码”AI Native 对员工的要求不是“人人会用提示词”这么浅。真正稀缺的能力有两类第一类是例外管理。当 Agent 遇到第四象限的未知问题或者某个自动化判断不可信时需要人接管。这个接管不是手动重复一遍而是判断“该不该让 Agent 继续、该不该改技能、该不该升级处置”。第二类是经验编码。把资深员工解决问题的过程拆解成可复用的技能和评估样例。这项工作很像早期软件行业的测试工程师和架构师不是做事的人变少了而是做事的方式变了。组织里最好有一个人人看得见的“问题类别看板”让每个团队都能看到哪些类别已在收敛哪些类别还在反复消耗人力。看板本身就是组织共识的锚点。6. 落地的真实教训我踩过的坑和补救办法最后分享几个我自己在实际推进 AI Native 时踩过的坑算是给正在搭这套体系的朋友提个醒。6.1 权限边界没设好Agent 差点把预发环境的配置改了第一次把 Agent 接到变更系统时我们给的权限偏大本意是想让 Agent 能自动回滚。结果在一次演练中Agent 因为误读了环境标签试图修改预发环境的配置。幸亏审计日志及时报警人拦了下来。之后我们把“默认最小权限”写进了 Harness 的默认配置任何写操作都要显式批准敏感动作必须双人复核。宁可效率低一点也不能让自动化失控。这一步让我对“Agent 安全”有了真正的体感。6.2 技能库变成“技能坟场”之后我们引入了技能 SLA项目初期我们兴致勃勃地封装了 30 多个技能但三个月后一看真正稳定的也就 8 个。大部分技能没人维护触发条件过时接口也早就变了。为了不让技能库变成坟场我们把技能当成一个“产品”来管每个技能必须有负责人、触发指标、回归测试集并且每季度 review 一次连续两个季度没人用的技能直接下线。这个过程很痛但利大于弊——少一半技能Agent 的稳定性反而提高了。6.3 抄别人评估集不如沉淀自己工单评估集要跟着问题类别长早期图省事我们找了一套公开的 Agent 评测集来跑分分数漂亮但上线后效果一般。后来才意识到公开评测集的问题分布和自家业务差太远。现在评估集完全从历史工单里长出来每新增一个问题类别就必须配套新增一类评估样例每次根因修复都必须用旧样例验证一次。评估集的大小不是目标覆盖度才是目标。这件事让我明白AI Native 的工程质量不能外包给通用数据集必须和自己企业的“问题类别地图”死死绑定。最后说一个我自己的判断AI Native 落地最大的分水岭不在模型参数也不在 Agent 数量而在企业有没有一套机制能持续把“反复出现的问题”变成“不再出现的能力”。技术组件只是载体组织愿意把注意力从答案转向根因才是转折点。我也还在这个过程中边踩坑边补课但至少我们已经不再满足于让 Agent 比人回答得更快了。