日志编译成Skill：让Agent历史经验自动沉淀

我最近在重构自己的 agent 工作流时一直在琢磨一个问题每次跑完一批任务日志里其实沉淀了大量“这次是怎么做成功的”信息但我基本不会回头翻看更别说把它们提炼成可复用的技能。直到我读到微软那篇关于提示词优化的论文思路——把 agent 的历史日志直接“编译”成下一版 Skill——才意识到这个方向才是提示词工程该走的路不再靠人手工总结而是让日志自己说话。这套思路的核心非常直接agent 在真实任务里留下的轨迹本质上就是最真实、最贴近实践的“操作手册”。把这些日志里可复用的部分提炼、去噪、结构化重新组装成一条新的 Skill 提示词就等于把过去的经验“编译”成了下一次行动的程序。和现在流行的“专家手工写 prompt 模板”“靠大模型自我反思优化”相比它更接近软件工程里的增量编译你改了多少就重新生成多少改得少、成本低、还能回滚。这篇文章我想拆一下这套方案给我的启发为什么“日志编译”比“手写 Skill”更可持续它的核心环节有哪些落地时最容易在哪几步翻车以及我试着把它用在现有 agent 流程里的具体体会。不管你是做 agent 应用开发、玩 Cursor/Codex 这类带 Skill 机制的 IDE还是单纯想把手头一堆零散的经验记录变成真正的生产力都值得往下看。1. 我为什么越来越不想“手写 Skill”在继续往下说之前先把 Skill 这个词说清楚。所谓 Skill在 agent 生态里可以理解成一段“带条件的操作经验提示词”当某类任务出现时agent 会把这段提示词加载进上下文按里面写好的步骤、约束和示例去执行。它本质上是一个可复用的操作流程封装只是载体是自然语言而不是代码。这个定义本身没问题真正让我头疼的是 Skill 的产生方式。1.1 现在的主流做法是“拍脑袋 人工打磨”打开 Cursor、Codex 或者类似的 agent 工具你会发现社区里大量 Skill 都是人写的某人做了一套流程觉得有效就把步骤抄下来配一个触发描述传到网上分享。这件事听起来很美好但我在实际使用中遇到了三个问题。第一人写的 Skill 往往偏离真实操作路径。我们写 Skill 的时候容易按“理想流程”去写比如我先做什么再做什么、遇到异常怎么办。但 agent 在真实环境里跑的时候根本不会按你预设的顺序走。它会根据中间结果动态跳步会尝试你没想到过的路径这些真实的“野路子”经验才是最有价值的而你手工写的时候根本写不出来因为你没意识到那也是一种方案。第二维护成本高到离谱。工具的 API 变了、页面结构变了、模型版本换了原来好用的 Skill 可能一夜之间全部失效。我手里大概维护着十几个常用 Skill每次都要手动跑一遍任务看哪里报错再手动调整提示词整个流程没有任何“回归测试”的概念纯粹靠记忆和感觉在修。第三评测基本靠感觉。我怎么知道改完一版 Skill 之后成功率真的提升了是提升了 3% 还是 30%我根本说不出来因为我没有一个统一的测评基准也没有对过去任务轨迹的量化对比。这导致每一次“优化”都像在盲调。1.2 日志里其实藏着“标准答案”如果你和我一样被上面三个问题困住过你大概也会同意这个观察agent 每次运行的日志才是它“实际做过什么”的唯一可靠记录。成功路径里藏着高效的操作组合失败路径里藏着系统边界和容易踩的坑。但我们平时压根没把这些日志当资产管理跑完就清偶尔要排查问题时才从终端里翻一翻。这其实浪费巨大。试想一下如果我能把过去 50 次成功完成“豆瓣读书数据抓取”的日志放在一起对比它们的共同操作顺序、过滤规则、页面解析策略然后自动生成一份统一的 Skill——它写出来的内容一定比我手敲的更贴合实际。因为它是从真实轨迹里统计出来的而不是我脑补出来的。微软这篇论文的思路恰好就是在解决这个问题把日志当输入把 Skill 当输出整个过程自动化。2. “编译”二字的分量日志到 Skill 不是拼接而是加工我第一次看到这个标题的时候注意点全在“编译”这个词上。你可以把“编译”理解成三步源代码经过词法分析、语法分析、语义分析最终生成目标代码。这个过程中最重要的是——它不改变源信息的语义但大幅改变它的组织形式。换句话说“把日志编译成 Skill”不是简单地把日志粘到 prompt 首部而是要做解析、抽象、去噪、重组。这套方案在我眼里的技术核心恰恰就是这四个动词。2.1 它到底在“编译”什么每个 agent 日志里都包含大量信息时间戳、用户输入、模型输出、工具调用的参数和返回结果、中间的错误信息。但这些东西并不都是 Skill 需要的。做行程规划的日志里时间戳是噪音调自然语言 API 的日志里长文本 response 也是噪音因为它每次内容都不同属于不可复现信息。Skill 真正需要的是“不变的骨架”——比如调用哪个工具、按什么顺序调用、判断条件是什么、遇到哪类报错时走什么分支。所以这套方案的输入不是原始日志而是“经过清洗的状态轨迹”。清洗后的结果是每一步做了什么操作、操作参数里哪些是固定的、哪些是任务相关的变量、哪些分支是成功的关键路径。比如一次失败后的重试日志里agent 第一次用分页参数page1抓豆瓣列表失败了看到返回结果里出现限流标识于是回到头部切换请求头、加了Referer参数再访问同一接口成功。清洗后沉淀进 Skill 的应该是“豆瓣列表接口第一次请求必须带 Referer否则会被限流”这条而不是记录它具体用了什么 UA因为在另一个环境里那个 UA 不一定好用。2.2 为什么要刻意用“编译”而不是“生成”我用“编译”这个词琢磨了很久后来发现它不是形容词而是对技术路线的准确描述。“生成”通常意味着大模型从零开始写出一段内容像如今大家都在玩的自反思式 prompt 优化——让大模型看一个任务描述和一次输出结果自己重写一版指令。这种方法的问题在于模型实际上是在“基于有限上下文猜测”最佳流程它没有看到历史的整体分布只看到了单个样本或最近几个样本。所以“生成”常常是直觉性的优化不能保证覆盖边界情况。“编译”则更像是把一条条执行轨迹当作源码通过合并同类项、提取公共操作、识别条件分支最终产出一份结构化的执行蓝图。这个产物不是模型自由发挥的结果而是逻辑合成出来的结果同一个操作路径如果出现在 80% 的成功日志里那它就大概率是稳定步骤可以进入 Skill。有一个很关键的区别在于生成追求的是“像不像一回事”而编译追求的是“是不是同一件事被完整表达”。3. 拆解“日志编译”的四个环节收集、筛选、结构化、验证看完论文里描述的核心思路也结合我自己的 agent 项目里对日志处理的经验我把它在实际落地时拆成了四个环节。每个环节单拎出来都不算复杂但连起来跑通需要你踩过不少细节坑。3.1 日志收集先定好“记录什么”很多人想到日志收集第一反应是“把 stdout 全存下来不就完了”。这远远不够stdout 只有输出没有输入和决策过程。我在自己的项目里会为每个任务单独建一份运行档案run profile包含这样几类数据任务初始描述用户给了什么目标、任务分解后形成的子目标序列、每一步工具调用的工具名与传参、工具返回结果的关键摘要、模型中间推理文本如果有的话、最终产出的结果或交付物。需要注意的是如果你用的是现成的 agent 框架比如 LangGraph、AutoGen 或最近社区很火的 agent harness 类方案它们通常已经自带 trace 能力只需要把 trace 落盘成 JSON 或 JSONL。如果用的是自研循环那你必须自己在工具调用层做一层包装记录器在每次工具调用前后打点。这一环没有做好后面环节全部无法展开。还有一个容易被忽略的点日志里要记录这个任务重跑的次数和每次之间的差异。如果同一个任务跑了两遍第二次因为缓存命中走了不同分支这个“分支切换的原因”对提炼 Skill 至关重要但在单次日志里是看不出来的。3.2 路径筛选不是所有操作都值得固化日志收集上来之后你面临的第一个问题是哪些日志值得用来提炼 Skill哪些应该直接抛弃我的筛选原则有三条。第一只看成功案例而且只拿“稳定成功”来用。如果同一个任务在 10 次运行里成功了 10 次路径高度一致那这部分几乎可以无脑提炼。如果只成功了 3 次且每次路径差异极大说明这个任务本身不稳定先不要提炼成 Skill先去查环境或模型的不确定来源否则提炼出来的 Skill 自己就是个哈希表。第二关注失败后重试成功的“二次路径”。这种日志的价值极高因为第一次失败往往暴露了系统的边界第二次成功则说明了正确的应对方式。错误信息本身要原样保留它是 Skill 里“判断条件”的最好素材。第三去掉包含巨量随机内容的日志。比如生成类任务模型每次输出都不一样这类日志里没有固定的操作规律唯一能提炼的只有“生成前置步骤”比如先做资料搜索、再写初稿、再格式化输出。你去看这类日志的时候要把注意力完全放在调用链上不要被生成的正文内容带偏。3.3 技能结构化稳定部分和易变部分要分离筛选完之后就到了核心环节把日志轨迹转成 Skill 结构。这一步如果做得过于粗糙直接拼接日志片段塞进 prompt效果会非常差。原因在于模型上下文是有窗口边界的日志越多样越容易把无关细节吸收进来。我目前的实践总结是Skill 结构至少要分三层稳定层无论任务的具体输入是什么这条路径一定适用。比如“调用天气接口之前必须先请求城市编码接口取得 location code”这属于稳定操作。稳定层可以原样写入 Skill 的 fixed steps。变量层任务不同参数不同。比如“查询城市天气”城市名是一个变量接口调用方式不变。这一层需要用占位符固化下来写成{city}的形式并在 Skill 里注明从哪里获取这个变量。条件层遇到特定异常时走特定分支。比如“如果接口返回 403切换请求头重试一次如果返回 500退避 3 秒后重试”。这一层是从失败日志里提炼的关键是传统手写 Skill 最常缺失的部分。把这三层拆完之后才能真正写出一份合格的 Skill prompt。我一般会用一个 JSON 结构来存储{ name: weather_query, trigger: 用户查询任意城市的实时天气, fixed_steps: [ {action: request_city_code, params: {city: {city}}}, {action: request_weather, params: {code: {code}}} ], conditional_branches: [ {cond: response.status 403, action: retry_with_header, param: {Referer: https://...}}, {cond: response.status 500, action: sleep_and_retry, param: {delay: 3}} ], output_format: 天气信息按 城市、温度、湿度、风力 四栏表格输出 }在生成 Skill 之前模型会自动做一次“模板抽取”把日志里所有非关键文本参数化。比如直接把城市名替换成占位符。这一步认真做完之后Skill 的可复用性会上升一个台阶。3.4 验证闭环用旧任务做回归测试编译出来的 Skill 不能直接上线得先跑一轮验证。我的做法是留出一部分历史日志作为“黄金测试集”里面包含 10 到 20 个代表性任务。每提炼一个新 Skill就用它跑一遍这组黄金任务记录成功率和耗时跟旧版本对比。这一步和软件工程里的回归测试非常像。没有这个闭环你就无法判断“日志编译出来的 Skill”到底是进步还是退步。我最初跑这套流程时发现很多自动提炼出来的 Skill 会把偶然的运气路径当成固定路径直接导致在黄金测试里成功率反而下降。验证跑完后我会把结果反馈回流程形成一个循环验证失败的任务轨迹再次进入日志池下一次提炼时会被当作负面样本参考让模型知道哪些路径不该出现在最终 Skill 中。4. 落地时最容易被坑的三类日志我的筛选红线流程跑通后真正让我栽跟头的不是技术实现而是数据质量问题。日志里总有那么几类样本看着像宝贵经验提炼到 Skill 里反而是毒药。4.1 “无效表演”式的失败日志agent 在出错时经常会出现一种让我哭笑不得的循环误以为工具调用成功了、实际上返回的是错误页、然后继续顺着错误页解析数据一路错到底最后“成功”地交出了一份全是错值的结果。这种日志最坑的地方在于从 agent 自己的视角看任务完成了但从外部客观视角看结果完全不可用。如果把这种日志纳入提炼池模型会把“拿到错误页也继续往下走”当成一种路径选择写进 Skill 后会让后续每次运行都走上错误的解析路径。我现在处理方式很简单在日志收集阶段就要求为每个任务打一个“结果校验标志”由后续的人工审查或另一个模型对交付物做质量评估质量不达标的日志直接不进 Skill 提炼池。宁可少提炼几个 Skill也不能把坏习惯编译进去。4.2 包含私有信息的日志这一点其实带点安全边界的意思历史日志里可能会包含用户邮箱、内部 API key、数据库连接串、甚至业务部署地址之类的敏感信息。如果这些内容被不加处理地编译进 Skill再随 Skill 分发到别的项目或团队成员手里等于把密钥散步到了不该去的地方。我踩过一次坑是把一个内网 API 的完整地址直接写进了生成的 Skill 模板里后来因为要分享给朋友参考不得不逐字检查整份 Skill才没造成问题。从那以后我在日志入库这一步就强制跑一轮脱敏把所有看起来像 token、密码、IP 地址、内网域名的字段替换成占位符。你要么靠正则硬过滤要么让一个独立模型做一次替换总之必须做不能偷懒。4.3 与现有 Skill 冲突的旧路径当你的 Skill 库里已经积累了一定数量会出现一个新的问题新提炼出来的路径跟已有 Skill 里固化的路径冲突。比如老 Skill 里写的是“抓取列表页时用/list?pageN” 新日志显示这个分页接口改版了必须换成 GraphQL 查询接口。这种冲突处理不好的话agent 在加载 Skill 时会出现指令打架一段说用旧接口一段说用新接口模型左右摇摆最后可能把两种方式都试一遍白白浪费调用次数。我现在的协作方法是在 Skill 描述里加一行supersedes字段专门记录它替代了哪个旧版本。等到自动提炼流程撞上冲突时直接把旧版本标记为 deprecated并在新 Skill 里附上一段“为什么接口要改”的说明文本。之所以要写明原因是因为模型在遇到日志里既有旧路径又有新路径时能根据原因自己判断应该优先采用哪条。5. 对比现有思路为什么“增量编译”比“重新进化”更适合工程环境聊到这里很多人会想到市面不是已经有 DSPy 这类自动优化提示词的框架吗也不是有大模型自反思优化的玩法吗“日志编译”和它们比起来优势到底在哪我做了个对比结论很明确——它们根本不在同一层东西。DSPy 和自反思优化是从“任务描述 若干样本”出发让模型改自己的 prompt本质上是在做“经验推断”。日志编译则是从“完整的执行轨迹”出发做的是“事实归纳”。我把关键差异列个表格维度自反思生成DSPy 式自动优化日志编译本篇思路数据来源单次输出样本任务描述 少量标注样例历史完整执行轨迹抽象层次提示词文字层面的改写模块化组合里的参数搜索操作路径的归纳与结构化对真实流程的还原度低容易捏造路径中取决于样例质量高来自真实轨迹统计可解释性低改完不知道为什么中可以看到组合方式高每个步骤都有日志来源容错性差一个错误样本就能带偏一般依赖采样分布好多次轨迹对照能剔除偶发路径适合的阶段快速试错期提示词已经稳定但需要调参时积累了足够日志后的持续迭代期这张表基本说明了我为什么更倾向日志编译它踩在真实经验上而不是踩在模型对经验的想象上。尤其是当你的 agent 应用已经跑了一段时间跨过“能不能跑通”的尝试阶段进入到“能不能稳定跑得好”的诉求阶段日志编译这套思路几乎就是最优解。而且它还有一层额外的优势可持续性。自反思优化经常是“每次优化都重跑一遍全部案例”计算开销巨大且每次输出都有随机性结果不稳定。而日志编译是增量的你只跳过最近新增的日志和最近改动过的工具模块不需要重新消化所有历史数据。这种“改多少就编多少”的风格对长期维护的 agent 项目来说非常友好。6. 把思路搬进自己项目时我的一线操作和几点体会理论说再多不如动手跑一遍。我拿自己一直在维护的一个信息整理型 agent 做实验试着把这套日志编译思路落了地。这部分的实操路线可能对你直接上手最有参考价值。6.1 冷启动先用高频任务跑出第一批 Skill如果你当前日志储备比较少不用急着上完整的自动化编译管线。我建议先做冷启动挑出项目里执行频率最高的三类任务比如“网页摘要生成”“结构化表格抽取”“定期监控并生成报告”让 agent 各跑 20 到 30 次形成第一批日志。再把这批日志按我前面说的方法处理一遍手工提取公共路径得到三份粗糙的初版 Skill。这一步为什么不用全自动因为冷启动阶段你还不知道数据里有哪些噪音也没有黄金测试集用来验证全自动提炼很可能把坏习惯固化下来。等到手动跑出三份可用的初版 Skill 后再引入自动提炼流程让系统持续从新日志中产出更新版本。6.2 版本化把 Skill 当代码管在我自己的实践中吃到最大红利的地方是把 Skill 当作代码来管理而不是当作文本文件随意覆盖。我会给每个 Skill 开一个独立目录里面包含skill.json结构定义、prompt.md提供给模型的最终提示词、test_cases/黄金测试集样例、CHANGELOG.md每次改动说明。所有自动编译产生的版本更新都通过讨论合并请求的方式进入主分支而不是直接覆盖线上版本。这样带来的直接好处是任何一次“编译”如果引发了成功率下降我可以立刻回滚到上一个版本如果想要对比两个版本的行为差异也可以在本地同时跑两轮测试。很多团队整天操心 agent 行为不可控但如果连 Skill 这种最核心的行为载体都没有版本管理那确实很难可控。6.3 我这段时间踩过的具体坑最后分享几个我在实验过程中遇到的细节问题它们都不在论文思路里但实操几乎都会碰到。一是日志轮转周期。如果日志只保留最近几天你可能会错过一个周期性的行为模式比如每周一接口限流更严重、需要更大的退避时间。我后来把日志保存周期拉长到 30 天并在提炼时按“最近 7 天 / 最近 30 天”两个窗口分别统计取两者都出现的稳定路径进入 Skill效果好很多。二是工具参数里的机密字段。我之前提过脱敏这里再补充一句脱敏要发生在“数据入库”时而不是发生在“编译生成 Skill 时”。因为编译过程通常需要多轮上下文整合如果等到编译前才脱敏前面的中间结果可能已经泄露。所以我现在的流水线在最前面就完成替换。三是保留“为什么失败”的文本。很多 agent 框架的 trace 默认只记录工具调用结果不记录模型的中间推理。但“为什么这个分支失败了”往往只写在模型的思考过程里。如果框架允许尽量把中间推理也落盘。实在取不到的话至少要知道失败后走了什么分支这是重建条件分支的唯一依据。我现在的开发循环已经完全转向这套“日志入库—路径筛选—Skill 编译—回归验证—版本发布”的机制。相比以前手改 prompt 的方式明显能感觉到每个 Skill 的更新都有据可依不再像盲人摸象。如果你也在做 agent 项目尤其是已经积累了几百条运行日志但还没想过怎么利用它们我真心建议你从冷启动那一步开始动手试一下。等跑通一轮你大概就理解为什么“日志编译”值得被当作 agent 开发的正式工程手段来对待。