我最近在盘点团队研发效能数据时发现一个特别扎心的现象同一个环境变量配置问题过去半年被人工工单处理了 35 次与此同时我们部署的 Agent 又单独跑了 28 次同样的排查流程。两边都在干活两边都在重复人和 Agent 之间像隔了一堵墙。这不是个别现象走访了几个也在推 AI Native 的团队几乎都有类似的症状同一类问题人也在解决Agent 也在解决却始终没有形成合力。这个现象背后藏着一个很本质的问题很多企业把 AI Native 理解成了“在现有流程里加一个 Agent”而不是“用 AI 重新设计解决问题的路径”。于是 Agent 变成了一个会干活的“新员工”但它和人之间没有知识传递、没有任务交接、没有经验沉淀。这篇文章我就围绕这个现象拆一拆为什么会这样以及怎么把人和 Agent 的重复劳动变成组织级资产。适合正在推 AI Native 转型、或者正在大规模上 Agent 的团队读也适合被“人机重复”困扰的技术管理者收藏。1. AI Native 到底改变了什么先看清问题出在哪一层1.1 AI Native 不是“加个 AI 功能”而是研发范式的重构很多团队对 AI Native 的理解还停留在“用大模型写代码、用 Copilot 补全、跑几个 Agent 自动化任务”这个层面。这其实不是 AI Native这是 AI 辅助或者说叫“AI Enhanced”。真正的 AI Native指的是从问题定义、方案设计、任务执行到结果验收的完整链路都围绕 AI 的能力来重新构建而不是把 AI 塞进原有的流程缝隙里。举个例子。传统研发范式下排查一个线上配置问题路径是人工发现异常 → 看日志 → 查配置 → 定位根因 → 修复 → 记录到知识库。整个链路里AI 可能只参与了“看日志”这一步比如用大模型总结一下日志里的关键信息。但其他环节还是人肉驱动的知识库里有没有沉淀、沉淀的质量如何完全取决于当事人的自觉性。AI Native 的范式下同样的排查问题应该被定义成一个标准任务触发条件是什么、需要调用哪些工具、每一步的决策点在哪里、失败回退策略是什么、结果要沉淀成什么格式。Agent 负责执行人负责定义边界和验收结果。这个重构不是优化了某个环节而是把“解决问题的过程”本身变成了一个可复用、可迭代、可评估的资产。1.2 人和 Agent 的定位变化从“人肉干活”到“人教 Agent 干活”在传统范式里人是执行者文档是沉淀物流程是约束。在 AI Native 范式里人的核心工作变成了三件事定义问题、教会 Agent 解决问题、验收 Agent 解决的结果。换句话说人从“自己解决问题”变成了“让 Agent 能解决问题”。但这个转变在很多团队里并没有真正完成。我看到的情况是团队领导拍板说“我们要 AI Native”然后技术负责人招了几个懂 Prompt Engineering 的人买了几个商业 Agent 平台的账号让大家搭几个 Agent 跑起来。结果呢Agent 是能跑了但人类工程师该干嘛还干嘛——该排查的问题照样排查该写的脚本照样写该回的工单照样回。Agent 在旁边忙活但在大多数情况下它并没有减少人的工作量反而增加了新的工作量比如要盯着 Agent、要帮 Agent 收拾烂摊子。这就是“同一类问题被人和 Agent 反复解决”的根源之一人和 Agent 的任务边界没有重新划分。大家都以为 AI Native 就是“加个人手”忘了它会从根本上改变任务的分配方式。如果人不从执行细节里解放出来不去做定义和验收的工作那 Agent 就只是一个额外的重复劳动力而不是替代性的解决方案。1.3 “重复解决”为什么会成为 AI Native 推进中的典型症状我把这个现象称为“AI Native 的重复症候群”它的典型表现是同一类问题的处理路径在人工通道和 Agent 通道里并行存在互不交叉。人工通道产生经验沉淀在人的脑子里或者 Wiki 里Agent 通道产生轨迹沉淀在会话日志里。两边都是“解决了一次”但都没有真正变成组织能力。这个症状在 AI Native 推进初期特别普遍原因也不难理解。第一Agent 的能力边界刚开始很窄只能覆盖一部分简单场景复杂的还是得人来第二还没有建立“问题注册制”什么该由 Agent 处理、什么该由人处理没有明确标准第三也是最关键的缺少一个“经验回灌”的机制让 Agent 每次执行的产出和教训能反过来优化下一次执行同时让人在处理新问题时能复用 Agent 的产出。没有这个机制人和 Agent 就永远是两条平行线。2. 三个典型场景同一类问题人和 Agent 各干各的2.1 场景一环境配置与故障排查我先说最典型的环境配置排查。一个中大型团队微服务几十个每个服务涉及配置文件、环境变量、依赖版本、中间件连接参数。新人入职要配环境老员工要排查环境问题运维要处理环境告警。这类问题有个特点总量大、单次耗时短、但架不住次数多。我们团队做过一次统计两个月时间里关于“某个服务连不上数据库”这类问题人工排查工单有 12 次Agent 自动排障执行了 20 多次。人工排查走的是看报错 → 看配置 → 查网络 → 试连接。Agent 走的是读取报错 → 调用配置查询接口 → 检查网络连通性 → 返回修复建议。两边处理的流程其实高度相似但结果完全隔离。人工排查后的结论可能写进了 WikiAgent 排障的日志则沉在会话历史里下次出了问题两边各自从头再来。这个场景特别能说明问题不是没有工具不是没有经验而是经验没有被结构化、任务化。人的经验是“我知道上次是端口配错了”Agent 的经验是“我上次成功定位了端口问题”但这两份经验没有合并成一条“标准排查路径”。如果把这个路径固化成 Agent 的标准任务并让 Agent 把每次执行的差异点回传给知识库人工工单的数量会明显下降。2.2 场景二重复的脚本开发与数据处理第二个典型场景是重复的脚本开发。业务部门隔三差五提需求“帮我把这个 Excel 清洗一下”“帮我批量重命名这批文件”“帮我从日志里提取某些字段”。工程师接到需求打开 IDE写一段 Python 脚本跑出结果发给业务方脚本躺在本地吃灰。上了 Agent 之后这类需求也有不少被分流到了 Agent 侧。但问题来了Agent 每次处理也是“现写现跑”它没有一个“脚本资产库”可以复用而工程师手头那些跑过的脚本也没有被整理成可复用的任务脚本。结果就是同一个“从 Excel 里提取指定列的日期格式并统一转换”的需求人写了一次脚本Agent 又写了一次下一次来了新需求两边又各写一遍。我见过最夸张的案例一个团队里同一个数据清洗逻辑出现了四份不同的话术一份在工程师的 GitHub 仓库里一份在 Agent 的执行日志里一份在 Wiki 文档里一份在另外一个人的本地目录里。四份内容大同小异但没有一份被定义为“标准任务”。这就是典型的缺乏任务资产化——只看见了一次次的结果没有看见背后可以被提取和复用的“问题处理模式”。2.3 场景三客服工单和内部问答第三个场景在客服和内部支持团队特别明显。用户问的问题高度重复比如“怎么重置密码”“怎么导出数据报表”“某个功能怎么开通权限”。传统方案是知识库人工回复上了 Agent 之后变成了知识库人工回复FAQ Bot但真正的问题在于人工回复和 Agent 回复的记录没有互相喂养。我们调研过很多团队的知识库更新还是靠客服团队成员手动整理。Agent 每天回答了几百个问题哪些问题答得好、哪些问题总是答偏这些数据没有回流到知识库维护者那里。结果就是Agent 永远在重复回答那些它本来就不擅长的问题客服人员也永远在重复处理那些 Agent 回答不了但实际很常见的问题。这个场景里“重复”变成了双重的用户重复提问人和 Agent 重复处理而处理过程中产生的改进信号又没有被有效收集。场景人的处理路径Agent 的处理路径核心问题环境配置排查看日志、查配置、试连接调接口、查状态、给修复建议经验不互通标准路径缺失脚本与数据处理现写脚本、跑完即弃每次重新推理生成脚本脚本资产未沉淀重复造轮子客服工单问答查知识库、手写回复检索知识库、生成回答回复质量数据未回流知识库三个场景的共同点是什么都是“问题本身高度相似但每次都被当成新问题处理”。人和 Agent 都在解决但解决过程的产出没有被组织化地收集、清洗、标准化。这才是重复的真正的成本——不是一次解决问题的成本而是每次都从零开始的成本。3. 根因拆解为什么人和 Agent 总在同一类问题上反复折腾3.1 Agent 的记忆是“会话级”的不是“组织级”的我在跟团队聊的时候反复强调一个容易被忽略的事实Agent 的记忆默认是会话级的。你让它处理一个问题它处理完了对话一关这次会话里的上下文、中间结果、优化思路就基本归零了。下次你再让它处理类似问题它又要重新理解、重新推理、重新生成方案。这和人的记忆其实很相似。但区别在于人有一套非正式的知识传递机制我会把踩过的坑告诉同事会在代码注释里写清楚“这里为什么会这么写”会整理到周报里。Agent 没有这个主动性它的记忆完全依赖于我们有没有建立“外部记忆系统”——也就是知识库、任务库、Skill 库、Agent 配置库。没有这些Agent 就是个每次都失忆的临时工。很多团队买 Agent 平台的时候看重的是对话能力、推理能力、工具调用能力往往忽略了记忆能力。结果 Agent 确实能干活但它不是一个越用越聪明的“老员工”而是反复失忆的“新员工”。人这边好不容易积累的经验Agent 那边一点没继承Agent 那边每次执行中产生的优质方案人也看不到。双通道并行、双通道模糊。3.2 缺少“问题注册制”同类问题没有被命名和归类这里我要提一个在传统软件工程里已经成熟、但 AI Native 范式下被严重忽略的方法问题注册。传统研发里每个 Bug 都有编号每个需求都有编号目的就是让“同类问题”可以被识别、被归类、被追踪。但到了 Agent 场景我们经常是“这个需求让 Agent 处理一下”“那个问题让 Agent 自动跑一下”没有给问题本身做分类和注册。没有注册就没有聚合。没有一个地方能回答“我们这个季度哪一类问题出现得最多哪一类问题被人工处理的次数最多哪一类问题 Agent 的解决率最低”这些问题我们偶尔可以从工单系统里挖出半份答案从 Agent 日志里挖出另外半份但很难对起来。而这两份数据对不上就意味着我们没有办法判断哪些问题应该优先做 Agent 化改造哪些问题 Agent 化之后效果显著哪些问题压根不适合 Agent。我给团队的建议一直很朴素先不着急写 Prompt、调 Agent先建一份《高频问题清单》。把过去三个月工单系统、客服记录、内部问答里出现的问题按照“问题类型、触发频率、处理时长、现有处理方式”四个维度做一张大表。这张表就是 Agent 化改造的地图。没有地图就开工大概率是乱打一气。3.3 人机协同边界没定义谁该负责沉淀成了“三不管”再往下挖一层就是协同机制的问题。同一类问题既能被人工处理、又能被 Agent 处理本身不是坏事但如果长期并行且没有明确的边界规则就会变成“三不管”工程团队觉得 Agent 的事由 AI 平台团队管AI 平台团队觉得问题处理的结果沉淀由业务团队管业务团队觉得流程优化是研发效能团队的事。结果就是Agent 跑出来的优质处理路径没人整理成 Skill人工处理中发现的共性规律没人固化成 Agent 的配置。大家都默认这事“应该有人管”但事实上没有人被明确授权。这里我需要引入一个在 Agent 工程界越来越受重视的概念harness控制框架。很多人觉得 harness 就是给 Agent 一套工具、一套 API让它能干活。我的理解比这个更宽harness 本质上是一套“人与 Agent 之间的协作契约”——它定义了哪些事 Agent 可以自主做、哪些事必须经过人确认、哪些事永远只能人来做、哪些信息必须回传给知识库。没有这个契约Agent 就是一个脱缰的“工具人”它的产出再漂亮也没法和人的工作体系融合。3.4 评估与验收机制缺位为什么“跑通了”不等于“解决问题”最后一个根因是评估体系没跟上。很多团队的 Agent 项目验收标准是“能不能跑通”。能跑通就算成功跑通了但解决率只有 40%也算成功跑通了但每次都需要人大量修正也算成功。这种验收标准直接导致了一个后果Agent 上线了但它的质量没有闭环反馈也就没有持续改进的压力。我见过一个团队上线了 20 多个 Agent大部分属于“demo 级可用”单次演示很惊艳实际跑起来要么准确率堪忧、要么动不动就卡壳。更麻烦的是这些 Agent 的成功率、失败原因、人工介入次数都没有系统化地统计。管理层问起来产出的只有“我们上了 20 个 Agent”这样一堆数字完全没有“它们解决了多少问题、节省了多少人力”这种价值型指标。没有评估就没有改进没有改进就没有信任。没有信任人就不会把问题放心地交给 Agent也不会认真把经验回灌给 Agent。于是人和 Agent 的循环就这么僵住了人觉得 Agent 不可靠Agent 觉得人没给它好东西两边都委屈问题却一遍遍重演。这个循环的破局点不在模型能力而在管理机制。4. 破局思路把“人和 Agent 的重复”拧成“组织级能力”4.1 第一步给问题做“注册”让人和 Agent 处理同一个“任务编号”要破局第一件事还是我前面说的建立问题注册制。具体做法是把高频问题清单里的每一项形成一个独立的任务定义。任务定义里至少包含四个要素任务名称比如“数据库连接失败排查”触发条件什么情况下这个任务会被创建处理路径人工处理的标准步骤 Agent 处理的推理路径验收标准什么算解决、什么算未解决、什么算需要人工介入任务定义完成后不管是人工工单还是 Agent 任务都挂上同一个任务编号。这样数据就能对起来这个任务被创建了多少次、人工处理了多少次、Agent 处理了多少次、各自效率如何、失败原因是什么。有了编号人和 Agent 的“重复动作”就变成了“同一任务的多次执行记录”可以分析、可以优化、可以做趋势判断。这里我补充一点实操建议任务注册不要搞成复杂的平台系统一开始用表格就能跑。关键是坚持两周以上的记录让人工处理和 Agent 处理的记录都进同一张表。数据量不需要太大三五十条记录就能看出规律了。4.2 第二步围绕“任务编号”设计人机协同流程有了任务编号之后下一步就是设计协同流程。我比较推荐的方式是给每个任务定义一个“默认处理方”和“升级路径”。比如某类问题默认由 Agent 处理但 Agent 连续两次处理失败或者解决置信度低于 60%必须升级给人工处理人工处理时系统要求把处理过程的关键步骤、工具调用、最终解决方案回填到任务记录里。这个流程听起来很普通但真正做到位的团队极少。常见的折中做法是Agent 处理失败就把问题转给人人处理完就完了没有回填。这样 Agent 永远学不会新的处理方式下次遇到同样的问题还会失败然后再次转给人。这就变成了“人和 Agent 的串联重复”比并联重复更消耗精力。正确的做法是人工处理完成后不只是“解决问题”还要“留下解法”。这个解法能不能转化成 Agent 的 Prompt 或 Skill需要另一段处理流程我下面单独讲。但至少任务记录里必须有一次完整的、结构化的处理轨迹这是 Agent 持续进化的养料。4.3 第三步建立“经验回灌”机制让 Agent 的失败喂给 Agent也让人的解法喂给 Agent经验回灌是破局的核心。所谓回灌就是把运行过程中产生的数据经过清洗、整理、标准化后变成 Agent 可复用资产的过程。我把它分成两条线一条线是“失败回灌”。Agent 处理失败不只是把任务转给人还要把失败原因记录下来是工具调用出错还是上下文缺失还是判断逻辑跑偏这些失败数据积累到一定量就是优化 Agent 的第一手素材。很多团队说 Agent 不聪明其实不是模型不聪明是它的失败模式没有被分析、没有被针对性地修正。另一条线是“人工解法回灌”。人工处理完一个任务后他的处理步骤是宝贵资产。把这个解法拆解成语义步骤转化成 Agent 的思维能力或者工具调用序列Agent 下次遇到类似问题就能参考。这个转化的过程可以让人做也可以让大模型辅助做但流程上一定要有专人负责。我印象很深的一个案例一个数据清洗任务人工处理时识别了一个规则——“日期格式为 yyyy/mm/dd 的条目转换前先检查时区字段如果时区非空则保留原格式”。这个规则被总结后配置到 Agent 里同类任务的解决率从 52% 直接升到 87%人工介入率下降了一半。这就是回灌的价值它不是换个更好的模型而是把实际业务中的隐性经验显性化。4.4 第四步从“Agent 开发”升级到“Agent 运营”知识沉淀成为考核指标最后一步是组织层面的机制升级。我的观点很明确Agent 的规模化落地关键不在开发在运营。开发是让 Agent 能处理一类问题运营是让 Agent 持续地、稳定地、可评估地处理一类问题并且在处理过程中不断变好。那么谁来负责运营我的建议是设立一个“Agent 运营”角色不一定是全职但必须有明确的职责他负责几件事监控 Agent 的任务解决率、人工介入率、失败原因分布收集人工处理任务时的解法和经验判断哪些可以回灌给 Agent维护任务定义库、Prompt 版本、Skill 资产定期把 Agent 的运行数据和人工处理数据合并分析优化任务分配策略这个角色不一定需要很强的 AI 技术背景但需要对业务流程有深度理解而且要有推动跨团队协作的能力。因为经验回灌本质上是一个跨流程的协作Agent 运营同学要能拉得动人推得动事。还有一点知识沉淀要进入考核。如果团队里没有任何一个人因为“整理了 20 条可复用的处理路径”而得到正反馈那这个机制迟早会死。我见过很多团队嘴上说知识沉淀很重要但在考核里完全没体现结果就是大家忙完业务火烧眉毛的事基本没人管沉淀。务必把“沉淀了多少优质任务路径”“Agent 解决率月度提升幅度”这类指标写进团队 OKR 里。不是说要搞形式而是给关键行为一个明确的信号这事值钱。5. 实操落地一套可直接抄作业的推进方案5.1 第一阶段盘点与分类1-2 周第一步工作很简单但最容易被低估花一两周时间把过去三个月的工单、客服记录、内部问答、日常沟通里出现的高频问题全部捞出来。然后按照问题类型做聚类识别出 Top 20 的重复性问题。做完聚类后对每一类问题做一个简单的价值评估评估维度有两个频率和价值。频率就是这类问题一个月出现多少次价值就是解决一次能节省多少时间、减少多少低级劳动。用这两个维度画个四象限高频高价值的问题优先做 Agent 化改造低频低价值的先放着低频高价值的做人工标准流程沉淀高频低价值的看情况自动化掉。这个盘点阶段千万不能省。我见过太多团队跳过盘点直接开始搭 Agent搭完之后发现搭的都是边角料场景真正痛的问题没覆盖到。盘点听起来不性感但它决定了后续投入的 ROI。5.2 第二阶段试点场景选择与任务定义2-4 周盘点之后从“高频高价值”象限里挑 2 到 3 个场景做试点。我的经验是试点场景要满足三个条件第一问题边界清晰输入输出可定义第二现有处理流程相对标准化有明确的步骤可以学习第三人工介入的参考案例足够多至少有过几十次成功处理记录。确定场景后就要写任务定义。这个阶段我会多花点时间不是因为写任务定义有多难而是因为它是所有后续工作的地基。任务定义写得好不好直接决定了 Agent 能不能稳定执行、人工能不能有效干预、经验能不能顺利沉淀。任务定义的模板我建议包含以下几项任务名精简、唯一、能对到业务场景目标任务完成后要达成的结果必须可验证输入任务启动时需要的全部信息处理流程分步骤描述允许分支工具与权限允许调用哪些工具、哪些数据源验收标准什么算成功什么算失败什么算需要升级回填要求处理完成后必须输出什么格式的记录打磨任务定义的时候建议让一线真正处理过这个问题的工程师参与评审。因为很多隐性知识比如“这个接口偶尔会返回 302需要重试一次”只写在一线工程师的脑子里。他们不参与Agent 就学不到。5.3 第三阶段定义人机分工与升级路径2-3 周试点场景跑起来之前还有一个环节要做定义人机分工。我推荐用“默认处理方 升级条件”的模型而不是把任务一刀切给 Agent 或者一刀切给人。默认处理方的选择取决于当前 Agent 的能力成熟度。能力不够时默认给人Agent 辅助提供排查建议能力足够时默认给 Agent人来兜底验收。要明确升级条件我建议定义三类情况必转人工一是 Agent 明确反馈“无法处理”二是 Agent 连续两次返回的结果与预期偏差大三是该任务的处理结果影响面大比如涉及生产变更、客户投诉、资金操作等。升级不是甩锅而是质量底线。没有底线Agent 的错误会扩散团队的信任会崩塌。这里我特别想强调人机分工不是一成不变的。随着 Agent 能力提升、经验回灌充足原本需要人工处理的任务可以逐渐切换到 Agent 优先。但切换必须基于数据而不是拍脑袋。看什么数据看 Agent 在对应任务上的历史解决率稳定超过一个阈值比如 90%再切低于阈值就维持人工兜底。5.4 第四阶段质量看板与持续优化持续进行最后一个环节是建立质量看板。我建议至少跟踪四个指标Agent 任务解决率Agent 自主完成且验收通过的比率人工介入率任务从 Agent 转给人工处理的比率平均处理时长任务从创建到关闭的总时长知识库沉淀量任务处理中产出的标准化解法、Skill、Prompt 的更新数量这四个指标不是互相独立的要放在一起看。比如人工介入率高不一定说明 Agent 差可能是任务定义里验收标准太高了解决率提升但耗时变长可能是 Agent 答得慢但答得准。看板的意义不只是监控而是引导复盘每个月的复盘会上问题清单重新过一遍看哪些问题的重复度下降了、哪些 Agent 化改造不达预期、哪些经验回灌产生了实际效果。我个人的经验这个循环跑三到四个月之后场景里的重复劳动能下降 40% 以上。不再是人一遍遍解决同样的问题也不再有 Agent 和人的“平行重复”而是人和 Agent 各司其职互补短板任务处理过程产生的每一份经验都在向下一次处理流动。6. 常见问题与避坑经验实录6.1 问题速查表这段时间跟不少团队交流把大家最常踩的坑整理成一张速查表方便对照自查。症状典型表现核心原因应对方案Agent 总是“失忆”同类问题换个说法就处理不了缺少外部记忆系统没有会话数据沉淀建立任务库和 Skill 库处理完必回填人工处理完不回填工程师解决问题后就直接关单回填流程繁琐缺乏正向激励简化回填模板纳入任务闭环回填可见Agent 频繁误报同一条件触发大量无效告警任务定义不完整误判边界不清晰迭代任务定义补充反例收紧触发条件人机责任模糊任务没人跟进出现空档缺少默认处理方升级路径不清晰明确分工模型三必转原则经验只停留在个人老员工懂Agent 不懂新人也不懂缺少组织级知识沉淀机制存量经验半结构化整理与任务编号关联Agent 单次很强、复用很差演示效果惊艳实际业务效果差任务覆盖面窄没有按高频问题注册重新盘点高频问题优先补齐 Top 场景表格里每个问题我基本都实操见过不是空泛的理论。最让我印象深刻的是一次 Agent 误报事故一个 Agent 在监控到某个服务响应时间超过阈值时自动触发了一个“重启服务”的操作。结果某天大量低峰期出现响应慢的报错Agent 疯狂重启把一批原本稳定的容器搞得很不稳定。事后排查发现原因就是任务定义里没有写清楚“什么情况下应该重新启动、什么情况下只需要标记观察”。后来我们给任务定义加了更细的分支条件和反例样本问题才算解决。6.2 几条独家的实操心得最后分享几条我在实际推进中攒下的心得不算什么高深理论但真的有用。第一** Agent 的 Prompt 和 Skill 一定要做版本管理**。前期可能觉得没那么重要等经验回灌多了、多版迭代之后你就明白了没有版本管理根本说不清上一次优化到底改了什么、是哪个改动导致解决率提升了 10 个百分点。我们甚至遇到过因配置回滚导致 Agent 行为“神秘地变了”的尴尬情况。把 Prompt 和 Skill 按 Git 思维来管凡改动必留痕这是 Agent 运营的底线。第二不要让 Agent“裸奔”上生产环境。我理解的“裸奔”不是说不做安全防护而是说没有给它提供足够的结构上下文。很多 Agent 运行环境完全没有给它访问知识库、调用内部工具、读取历史案例的能力一上来就让它凭空推理结果自然是既不准也不稳。Agent 不是仙童它没有上下文就撂挑子有上下文才能干好活。第三一个任务不要只做一个 Prompt要做成“技能包”。Prompt 只是入口真正稳定的是把工具调用清单、知识库检索策略、边界条件、反例样本整合成一个技能包来管理。技能包不是一次写成的而是在多次执行、多次失败回灌中迭代出来的。好的技能包可能一个季度会迭代十几次每次迭代背后都是真实的执行数据。第四把“这个 Agent 解决了什么、没解决什么”当成第一行输出。我让团队在每个 Agent 任务结束时强制输出一段“任务复盘”写清楚这一轮任务解决了哪些问题、用什么方法解决的、哪些问题没解决、为什么没解决、下一次执行请注意什么。这五句话远比日志里的原始堆栈有价值。它既是给人看的验收结论也是给下一次 Agent 执行的“记忆线头”。我在这段时间的实操里慢慢体会到“AI Native 推进不顺利”这个命题极少是技术瓶颈更多是组织和管理问题。模型不够好可以换更强的模型Agent 能力弱可以加编排、加工具但人和 Agent 之间的重复劳动不消除换什么模型都白搭——因为问题的根子不在于“AI 能不能解决”而在于“解决完为什么没有留下来”。想通了这一点推进 AI Native 的核心工作就很清楚了把问题注册好把任务定义好把经验回灌好。剩下的交给模型和时间。 AI Native转型中，如何把人和Agent的重复劳动变成组织级资产
我最近在盘点团队研发效能数据时发现一个特别扎心的现象同一个环境变量配置问题过去半年被人工工单处理了 35 次与此同时我们部署的 Agent 又单独跑了 28 次同样的排查流程。两边都在干活两边都在重复人和 Agent 之间像隔了一堵墙。这不是个别现象走访了几个也在推 AI Native 的团队几乎都有类似的症状同一类问题人也在解决Agent 也在解决却始终没有形成合力。这个现象背后藏着一个很本质的问题很多企业把 AI Native 理解成了“在现有流程里加一个 Agent”而不是“用 AI 重新设计解决问题的路径”。于是 Agent 变成了一个会干活的“新员工”但它和人之间没有知识传递、没有任务交接、没有经验沉淀。这篇文章我就围绕这个现象拆一拆为什么会这样以及怎么把人和 Agent 的重复劳动变成组织级资产。适合正在推 AI Native 转型、或者正在大规模上 Agent 的团队读也适合被“人机重复”困扰的技术管理者收藏。1. AI Native 到底改变了什么先看清问题出在哪一层1.1 AI Native 不是“加个 AI 功能”而是研发范式的重构很多团队对 AI Native 的理解还停留在“用大模型写代码、用 Copilot 补全、跑几个 Agent 自动化任务”这个层面。这其实不是 AI Native这是 AI 辅助或者说叫“AI Enhanced”。真正的 AI Native指的是从问题定义、方案设计、任务执行到结果验收的完整链路都围绕 AI 的能力来重新构建而不是把 AI 塞进原有的流程缝隙里。举个例子。传统研发范式下排查一个线上配置问题路径是人工发现异常 → 看日志 → 查配置 → 定位根因 → 修复 → 记录到知识库。整个链路里AI 可能只参与了“看日志”这一步比如用大模型总结一下日志里的关键信息。但其他环节还是人肉驱动的知识库里有没有沉淀、沉淀的质量如何完全取决于当事人的自觉性。AI Native 的范式下同样的排查问题应该被定义成一个标准任务触发条件是什么、需要调用哪些工具、每一步的决策点在哪里、失败回退策略是什么、结果要沉淀成什么格式。Agent 负责执行人负责定义边界和验收结果。这个重构不是优化了某个环节而是把“解决问题的过程”本身变成了一个可复用、可迭代、可评估的资产。1.2 人和 Agent 的定位变化从“人肉干活”到“人教 Agent 干活”在传统范式里人是执行者文档是沉淀物流程是约束。在 AI Native 范式里人的核心工作变成了三件事定义问题、教会 Agent 解决问题、验收 Agent 解决的结果。换句话说人从“自己解决问题”变成了“让 Agent 能解决问题”。但这个转变在很多团队里并没有真正完成。我看到的情况是团队领导拍板说“我们要 AI Native”然后技术负责人招了几个懂 Prompt Engineering 的人买了几个商业 Agent 平台的账号让大家搭几个 Agent 跑起来。结果呢Agent 是能跑了但人类工程师该干嘛还干嘛——该排查的问题照样排查该写的脚本照样写该回的工单照样回。Agent 在旁边忙活但在大多数情况下它并没有减少人的工作量反而增加了新的工作量比如要盯着 Agent、要帮 Agent 收拾烂摊子。这就是“同一类问题被人和 Agent 反复解决”的根源之一人和 Agent 的任务边界没有重新划分。大家都以为 AI Native 就是“加个人手”忘了它会从根本上改变任务的分配方式。如果人不从执行细节里解放出来不去做定义和验收的工作那 Agent 就只是一个额外的重复劳动力而不是替代性的解决方案。1.3 “重复解决”为什么会成为 AI Native 推进中的典型症状我把这个现象称为“AI Native 的重复症候群”它的典型表现是同一类问题的处理路径在人工通道和 Agent 通道里并行存在互不交叉。人工通道产生经验沉淀在人的脑子里或者 Wiki 里Agent 通道产生轨迹沉淀在会话日志里。两边都是“解决了一次”但都没有真正变成组织能力。这个症状在 AI Native 推进初期特别普遍原因也不难理解。第一Agent 的能力边界刚开始很窄只能覆盖一部分简单场景复杂的还是得人来第二还没有建立“问题注册制”什么该由 Agent 处理、什么该由人处理没有明确标准第三也是最关键的缺少一个“经验回灌”的机制让 Agent 每次执行的产出和教训能反过来优化下一次执行同时让人在处理新问题时能复用 Agent 的产出。没有这个机制人和 Agent 就永远是两条平行线。2. 三个典型场景同一类问题人和 Agent 各干各的2.1 场景一环境配置与故障排查我先说最典型的环境配置排查。一个中大型团队微服务几十个每个服务涉及配置文件、环境变量、依赖版本、中间件连接参数。新人入职要配环境老员工要排查环境问题运维要处理环境告警。这类问题有个特点总量大、单次耗时短、但架不住次数多。我们团队做过一次统计两个月时间里关于“某个服务连不上数据库”这类问题人工排查工单有 12 次Agent 自动排障执行了 20 多次。人工排查走的是看报错 → 看配置 → 查网络 → 试连接。Agent 走的是读取报错 → 调用配置查询接口 → 检查网络连通性 → 返回修复建议。两边处理的流程其实高度相似但结果完全隔离。人工排查后的结论可能写进了 WikiAgent 排障的日志则沉在会话历史里下次出了问题两边各自从头再来。这个场景特别能说明问题不是没有工具不是没有经验而是经验没有被结构化、任务化。人的经验是“我知道上次是端口配错了”Agent 的经验是“我上次成功定位了端口问题”但这两份经验没有合并成一条“标准排查路径”。如果把这个路径固化成 Agent 的标准任务并让 Agent 把每次执行的差异点回传给知识库人工工单的数量会明显下降。2.2 场景二重复的脚本开发与数据处理第二个典型场景是重复的脚本开发。业务部门隔三差五提需求“帮我把这个 Excel 清洗一下”“帮我批量重命名这批文件”“帮我从日志里提取某些字段”。工程师接到需求打开 IDE写一段 Python 脚本跑出结果发给业务方脚本躺在本地吃灰。上了 Agent 之后这类需求也有不少被分流到了 Agent 侧。但问题来了Agent 每次处理也是“现写现跑”它没有一个“脚本资产库”可以复用而工程师手头那些跑过的脚本也没有被整理成可复用的任务脚本。结果就是同一个“从 Excel 里提取指定列的日期格式并统一转换”的需求人写了一次脚本Agent 又写了一次下一次来了新需求两边又各写一遍。我见过最夸张的案例一个团队里同一个数据清洗逻辑出现了四份不同的话术一份在工程师的 GitHub 仓库里一份在 Agent 的执行日志里一份在 Wiki 文档里一份在另外一个人的本地目录里。四份内容大同小异但没有一份被定义为“标准任务”。这就是典型的缺乏任务资产化——只看见了一次次的结果没有看见背后可以被提取和复用的“问题处理模式”。2.3 场景三客服工单和内部问答第三个场景在客服和内部支持团队特别明显。用户问的问题高度重复比如“怎么重置密码”“怎么导出数据报表”“某个功能怎么开通权限”。传统方案是知识库人工回复上了 Agent 之后变成了知识库人工回复FAQ Bot但真正的问题在于人工回复和 Agent 回复的记录没有互相喂养。我们调研过很多团队的知识库更新还是靠客服团队成员手动整理。Agent 每天回答了几百个问题哪些问题答得好、哪些问题总是答偏这些数据没有回流到知识库维护者那里。结果就是Agent 永远在重复回答那些它本来就不擅长的问题客服人员也永远在重复处理那些 Agent 回答不了但实际很常见的问题。这个场景里“重复”变成了双重的用户重复提问人和 Agent 重复处理而处理过程中产生的改进信号又没有被有效收集。场景人的处理路径Agent 的处理路径核心问题环境配置排查看日志、查配置、试连接调接口、查状态、给修复建议经验不互通标准路径缺失脚本与数据处理现写脚本、跑完即弃每次重新推理生成脚本脚本资产未沉淀重复造轮子客服工单问答查知识库、手写回复检索知识库、生成回答回复质量数据未回流知识库三个场景的共同点是什么都是“问题本身高度相似但每次都被当成新问题处理”。人和 Agent 都在解决但解决过程的产出没有被组织化地收集、清洗、标准化。这才是重复的真正的成本——不是一次解决问题的成本而是每次都从零开始的成本。3. 根因拆解为什么人和 Agent 总在同一类问题上反复折腾3.1 Agent 的记忆是“会话级”的不是“组织级”的我在跟团队聊的时候反复强调一个容易被忽略的事实Agent 的记忆默认是会话级的。你让它处理一个问题它处理完了对话一关这次会话里的上下文、中间结果、优化思路就基本归零了。下次你再让它处理类似问题它又要重新理解、重新推理、重新生成方案。这和人的记忆其实很相似。但区别在于人有一套非正式的知识传递机制我会把踩过的坑告诉同事会在代码注释里写清楚“这里为什么会这么写”会整理到周报里。Agent 没有这个主动性它的记忆完全依赖于我们有没有建立“外部记忆系统”——也就是知识库、任务库、Skill 库、Agent 配置库。没有这些Agent 就是个每次都失忆的临时工。很多团队买 Agent 平台的时候看重的是对话能力、推理能力、工具调用能力往往忽略了记忆能力。结果 Agent 确实能干活但它不是一个越用越聪明的“老员工”而是反复失忆的“新员工”。人这边好不容易积累的经验Agent 那边一点没继承Agent 那边每次执行中产生的优质方案人也看不到。双通道并行、双通道模糊。3.2 缺少“问题注册制”同类问题没有被命名和归类这里我要提一个在传统软件工程里已经成熟、但 AI Native 范式下被严重忽略的方法问题注册。传统研发里每个 Bug 都有编号每个需求都有编号目的就是让“同类问题”可以被识别、被归类、被追踪。但到了 Agent 场景我们经常是“这个需求让 Agent 处理一下”“那个问题让 Agent 自动跑一下”没有给问题本身做分类和注册。没有注册就没有聚合。没有一个地方能回答“我们这个季度哪一类问题出现得最多哪一类问题被人工处理的次数最多哪一类问题 Agent 的解决率最低”这些问题我们偶尔可以从工单系统里挖出半份答案从 Agent 日志里挖出另外半份但很难对起来。而这两份数据对不上就意味着我们没有办法判断哪些问题应该优先做 Agent 化改造哪些问题 Agent 化之后效果显著哪些问题压根不适合 Agent。我给团队的建议一直很朴素先不着急写 Prompt、调 Agent先建一份《高频问题清单》。把过去三个月工单系统、客服记录、内部问答里出现的问题按照“问题类型、触发频率、处理时长、现有处理方式”四个维度做一张大表。这张表就是 Agent 化改造的地图。没有地图就开工大概率是乱打一气。3.3 人机协同边界没定义谁该负责沉淀成了“三不管”再往下挖一层就是协同机制的问题。同一类问题既能被人工处理、又能被 Agent 处理本身不是坏事但如果长期并行且没有明确的边界规则就会变成“三不管”工程团队觉得 Agent 的事由 AI 平台团队管AI 平台团队觉得问题处理的结果沉淀由业务团队管业务团队觉得流程优化是研发效能团队的事。结果就是Agent 跑出来的优质处理路径没人整理成 Skill人工处理中发现的共性规律没人固化成 Agent 的配置。大家都默认这事“应该有人管”但事实上没有人被明确授权。这里我需要引入一个在 Agent 工程界越来越受重视的概念harness控制框架。很多人觉得 harness 就是给 Agent 一套工具、一套 API让它能干活。我的理解比这个更宽harness 本质上是一套“人与 Agent 之间的协作契约”——它定义了哪些事 Agent 可以自主做、哪些事必须经过人确认、哪些事永远只能人来做、哪些信息必须回传给知识库。没有这个契约Agent 就是一个脱缰的“工具人”它的产出再漂亮也没法和人的工作体系融合。3.4 评估与验收机制缺位为什么“跑通了”不等于“解决问题”最后一个根因是评估体系没跟上。很多团队的 Agent 项目验收标准是“能不能跑通”。能跑通就算成功跑通了但解决率只有 40%也算成功跑通了但每次都需要人大量修正也算成功。这种验收标准直接导致了一个后果Agent 上线了但它的质量没有闭环反馈也就没有持续改进的压力。我见过一个团队上线了 20 多个 Agent大部分属于“demo 级可用”单次演示很惊艳实际跑起来要么准确率堪忧、要么动不动就卡壳。更麻烦的是这些 Agent 的成功率、失败原因、人工介入次数都没有系统化地统计。管理层问起来产出的只有“我们上了 20 个 Agent”这样一堆数字完全没有“它们解决了多少问题、节省了多少人力”这种价值型指标。没有评估就没有改进没有改进就没有信任。没有信任人就不会把问题放心地交给 Agent也不会认真把经验回灌给 Agent。于是人和 Agent 的循环就这么僵住了人觉得 Agent 不可靠Agent 觉得人没给它好东西两边都委屈问题却一遍遍重演。这个循环的破局点不在模型能力而在管理机制。4. 破局思路把“人和 Agent 的重复”拧成“组织级能力”4.1 第一步给问题做“注册”让人和 Agent 处理同一个“任务编号”要破局第一件事还是我前面说的建立问题注册制。具体做法是把高频问题清单里的每一项形成一个独立的任务定义。任务定义里至少包含四个要素任务名称比如“数据库连接失败排查”触发条件什么情况下这个任务会被创建处理路径人工处理的标准步骤 Agent 处理的推理路径验收标准什么算解决、什么算未解决、什么算需要人工介入任务定义完成后不管是人工工单还是 Agent 任务都挂上同一个任务编号。这样数据就能对起来这个任务被创建了多少次、人工处理了多少次、Agent 处理了多少次、各自效率如何、失败原因是什么。有了编号人和 Agent 的“重复动作”就变成了“同一任务的多次执行记录”可以分析、可以优化、可以做趋势判断。这里我补充一点实操建议任务注册不要搞成复杂的平台系统一开始用表格就能跑。关键是坚持两周以上的记录让人工处理和 Agent 处理的记录都进同一张表。数据量不需要太大三五十条记录就能看出规律了。4.2 第二步围绕“任务编号”设计人机协同流程有了任务编号之后下一步就是设计协同流程。我比较推荐的方式是给每个任务定义一个“默认处理方”和“升级路径”。比如某类问题默认由 Agent 处理但 Agent 连续两次处理失败或者解决置信度低于 60%必须升级给人工处理人工处理时系统要求把处理过程的关键步骤、工具调用、最终解决方案回填到任务记录里。这个流程听起来很普通但真正做到位的团队极少。常见的折中做法是Agent 处理失败就把问题转给人人处理完就完了没有回填。这样 Agent 永远学不会新的处理方式下次遇到同样的问题还会失败然后再次转给人。这就变成了“人和 Agent 的串联重复”比并联重复更消耗精力。正确的做法是人工处理完成后不只是“解决问题”还要“留下解法”。这个解法能不能转化成 Agent 的 Prompt 或 Skill需要另一段处理流程我下面单独讲。但至少任务记录里必须有一次完整的、结构化的处理轨迹这是 Agent 持续进化的养料。4.3 第三步建立“经验回灌”机制让 Agent 的失败喂给 Agent也让人的解法喂给 Agent经验回灌是破局的核心。所谓回灌就是把运行过程中产生的数据经过清洗、整理、标准化后变成 Agent 可复用资产的过程。我把它分成两条线一条线是“失败回灌”。Agent 处理失败不只是把任务转给人还要把失败原因记录下来是工具调用出错还是上下文缺失还是判断逻辑跑偏这些失败数据积累到一定量就是优化 Agent 的第一手素材。很多团队说 Agent 不聪明其实不是模型不聪明是它的失败模式没有被分析、没有被针对性地修正。另一条线是“人工解法回灌”。人工处理完一个任务后他的处理步骤是宝贵资产。把这个解法拆解成语义步骤转化成 Agent 的思维能力或者工具调用序列Agent 下次遇到类似问题就能参考。这个转化的过程可以让人做也可以让大模型辅助做但流程上一定要有专人负责。我印象很深的一个案例一个数据清洗任务人工处理时识别了一个规则——“日期格式为 yyyy/mm/dd 的条目转换前先检查时区字段如果时区非空则保留原格式”。这个规则被总结后配置到 Agent 里同类任务的解决率从 52% 直接升到 87%人工介入率下降了一半。这就是回灌的价值它不是换个更好的模型而是把实际业务中的隐性经验显性化。4.4 第四步从“Agent 开发”升级到“Agent 运营”知识沉淀成为考核指标最后一步是组织层面的机制升级。我的观点很明确Agent 的规模化落地关键不在开发在运营。开发是让 Agent 能处理一类问题运营是让 Agent 持续地、稳定地、可评估地处理一类问题并且在处理过程中不断变好。那么谁来负责运营我的建议是设立一个“Agent 运营”角色不一定是全职但必须有明确的职责他负责几件事监控 Agent 的任务解决率、人工介入率、失败原因分布收集人工处理任务时的解法和经验判断哪些可以回灌给 Agent维护任务定义库、Prompt 版本、Skill 资产定期把 Agent 的运行数据和人工处理数据合并分析优化任务分配策略这个角色不一定需要很强的 AI 技术背景但需要对业务流程有深度理解而且要有推动跨团队协作的能力。因为经验回灌本质上是一个跨流程的协作Agent 运营同学要能拉得动人推得动事。还有一点知识沉淀要进入考核。如果团队里没有任何一个人因为“整理了 20 条可复用的处理路径”而得到正反馈那这个机制迟早会死。我见过很多团队嘴上说知识沉淀很重要但在考核里完全没体现结果就是大家忙完业务火烧眉毛的事基本没人管沉淀。务必把“沉淀了多少优质任务路径”“Agent 解决率月度提升幅度”这类指标写进团队 OKR 里。不是说要搞形式而是给关键行为一个明确的信号这事值钱。5. 实操落地一套可直接抄作业的推进方案5.1 第一阶段盘点与分类1-2 周第一步工作很简单但最容易被低估花一两周时间把过去三个月的工单、客服记录、内部问答、日常沟通里出现的高频问题全部捞出来。然后按照问题类型做聚类识别出 Top 20 的重复性问题。做完聚类后对每一类问题做一个简单的价值评估评估维度有两个频率和价值。频率就是这类问题一个月出现多少次价值就是解决一次能节省多少时间、减少多少低级劳动。用这两个维度画个四象限高频高价值的问题优先做 Agent 化改造低频低价值的先放着低频高价值的做人工标准流程沉淀高频低价值的看情况自动化掉。这个盘点阶段千万不能省。我见过太多团队跳过盘点直接开始搭 Agent搭完之后发现搭的都是边角料场景真正痛的问题没覆盖到。盘点听起来不性感但它决定了后续投入的 ROI。5.2 第二阶段试点场景选择与任务定义2-4 周盘点之后从“高频高价值”象限里挑 2 到 3 个场景做试点。我的经验是试点场景要满足三个条件第一问题边界清晰输入输出可定义第二现有处理流程相对标准化有明确的步骤可以学习第三人工介入的参考案例足够多至少有过几十次成功处理记录。确定场景后就要写任务定义。这个阶段我会多花点时间不是因为写任务定义有多难而是因为它是所有后续工作的地基。任务定义写得好不好直接决定了 Agent 能不能稳定执行、人工能不能有效干预、经验能不能顺利沉淀。任务定义的模板我建议包含以下几项任务名精简、唯一、能对到业务场景目标任务完成后要达成的结果必须可验证输入任务启动时需要的全部信息处理流程分步骤描述允许分支工具与权限允许调用哪些工具、哪些数据源验收标准什么算成功什么算失败什么算需要升级回填要求处理完成后必须输出什么格式的记录打磨任务定义的时候建议让一线真正处理过这个问题的工程师参与评审。因为很多隐性知识比如“这个接口偶尔会返回 302需要重试一次”只写在一线工程师的脑子里。他们不参与Agent 就学不到。5.3 第三阶段定义人机分工与升级路径2-3 周试点场景跑起来之前还有一个环节要做定义人机分工。我推荐用“默认处理方 升级条件”的模型而不是把任务一刀切给 Agent 或者一刀切给人。默认处理方的选择取决于当前 Agent 的能力成熟度。能力不够时默认给人Agent 辅助提供排查建议能力足够时默认给 Agent人来兜底验收。要明确升级条件我建议定义三类情况必转人工一是 Agent 明确反馈“无法处理”二是 Agent 连续两次返回的结果与预期偏差大三是该任务的处理结果影响面大比如涉及生产变更、客户投诉、资金操作等。升级不是甩锅而是质量底线。没有底线Agent 的错误会扩散团队的信任会崩塌。这里我特别想强调人机分工不是一成不变的。随着 Agent 能力提升、经验回灌充足原本需要人工处理的任务可以逐渐切换到 Agent 优先。但切换必须基于数据而不是拍脑袋。看什么数据看 Agent 在对应任务上的历史解决率稳定超过一个阈值比如 90%再切低于阈值就维持人工兜底。5.4 第四阶段质量看板与持续优化持续进行最后一个环节是建立质量看板。我建议至少跟踪四个指标Agent 任务解决率Agent 自主完成且验收通过的比率人工介入率任务从 Agent 转给人工处理的比率平均处理时长任务从创建到关闭的总时长知识库沉淀量任务处理中产出的标准化解法、Skill、Prompt 的更新数量这四个指标不是互相独立的要放在一起看。比如人工介入率高不一定说明 Agent 差可能是任务定义里验收标准太高了解决率提升但耗时变长可能是 Agent 答得慢但答得准。看板的意义不只是监控而是引导复盘每个月的复盘会上问题清单重新过一遍看哪些问题的重复度下降了、哪些 Agent 化改造不达预期、哪些经验回灌产生了实际效果。我个人的经验这个循环跑三到四个月之后场景里的重复劳动能下降 40% 以上。不再是人一遍遍解决同样的问题也不再有 Agent 和人的“平行重复”而是人和 Agent 各司其职互补短板任务处理过程产生的每一份经验都在向下一次处理流动。6. 常见问题与避坑经验实录6.1 问题速查表这段时间跟不少团队交流把大家最常踩的坑整理成一张速查表方便对照自查。症状典型表现核心原因应对方案Agent 总是“失忆”同类问题换个说法就处理不了缺少外部记忆系统没有会话数据沉淀建立任务库和 Skill 库处理完必回填人工处理完不回填工程师解决问题后就直接关单回填流程繁琐缺乏正向激励简化回填模板纳入任务闭环回填可见Agent 频繁误报同一条件触发大量无效告警任务定义不完整误判边界不清晰迭代任务定义补充反例收紧触发条件人机责任模糊任务没人跟进出现空档缺少默认处理方升级路径不清晰明确分工模型三必转原则经验只停留在个人老员工懂Agent 不懂新人也不懂缺少组织级知识沉淀机制存量经验半结构化整理与任务编号关联Agent 单次很强、复用很差演示效果惊艳实际业务效果差任务覆盖面窄没有按高频问题注册重新盘点高频问题优先补齐 Top 场景表格里每个问题我基本都实操见过不是空泛的理论。最让我印象深刻的是一次 Agent 误报事故一个 Agent 在监控到某个服务响应时间超过阈值时自动触发了一个“重启服务”的操作。结果某天大量低峰期出现响应慢的报错Agent 疯狂重启把一批原本稳定的容器搞得很不稳定。事后排查发现原因就是任务定义里没有写清楚“什么情况下应该重新启动、什么情况下只需要标记观察”。后来我们给任务定义加了更细的分支条件和反例样本问题才算解决。6.2 几条独家的实操心得最后分享几条我在实际推进中攒下的心得不算什么高深理论但真的有用。第一** Agent 的 Prompt 和 Skill 一定要做版本管理**。前期可能觉得没那么重要等经验回灌多了、多版迭代之后你就明白了没有版本管理根本说不清上一次优化到底改了什么、是哪个改动导致解决率提升了 10 个百分点。我们甚至遇到过因配置回滚导致 Agent 行为“神秘地变了”的尴尬情况。把 Prompt 和 Skill 按 Git 思维来管凡改动必留痕这是 Agent 运营的底线。第二不要让 Agent“裸奔”上生产环境。我理解的“裸奔”不是说不做安全防护而是说没有给它提供足够的结构上下文。很多 Agent 运行环境完全没有给它访问知识库、调用内部工具、读取历史案例的能力一上来就让它凭空推理结果自然是既不准也不稳。Agent 不是仙童它没有上下文就撂挑子有上下文才能干好活。第三一个任务不要只做一个 Prompt要做成“技能包”。Prompt 只是入口真正稳定的是把工具调用清单、知识库检索策略、边界条件、反例样本整合成一个技能包来管理。技能包不是一次写成的而是在多次执行、多次失败回灌中迭代出来的。好的技能包可能一个季度会迭代十几次每次迭代背后都是真实的执行数据。第四把“这个 Agent 解决了什么、没解决什么”当成第一行输出。我让团队在每个 Agent 任务结束时强制输出一段“任务复盘”写清楚这一轮任务解决了哪些问题、用什么方法解决的、哪些问题没解决、为什么没解决、下一次执行请注意什么。这五句话远比日志里的原始堆栈有价值。它既是给人看的验收结论也是给下一次 Agent 执行的“记忆线头”。我在这段时间的实操里慢慢体会到“AI Native 推进不顺利”这个命题极少是技术瓶颈更多是组织和管理问题。模型不够好可以换更强的模型Agent 能力弱可以加编排、加工具但人和 Agent 之间的重复劳动不消除换什么模型都白搭——因为问题的根子不在于“AI 能不能解决”而在于“解决完为什么没有留下来”。想通了这一点推进 AI Native 的核心工作就很清楚了把问题注册好把任务定义好把经验回灌好。剩下的交给模型和时间。