上个月我差点因为一次模型接入的翻车把整个自动化项目砍掉。当时我按照接口文档把模型接了进来写了三百多行调用脚本结果第一版上线不到半天就连续翻车模型返回的 JSON 时而多一个字段、时而把字段名从下划线变成驼峰日志一多就开始答非所问最夸张的一次是同一个请求连续返回了十几条一模一样的废话。排查了两天确认不是模型本身的问题之后我换了个思路用 WorkBuddy 把模型重新封装成一个 Skill。二十天、十五轮迭代最终把这个接不稳的模型变成了一个基本不用人工盯的自动化模块。这篇文章就是这次接入的完整实录从翻车复盘到选型逻辑再到每一轮迭代的具体改动最后是我沉淀下来的一些边界条件和通用经验。无论你是在接外部模型、做 Agent 工作流还是单纯想把手里的模型能力沉淀成可复用模块这篇记录应该都能给你一些参考。1. 翻车复盘模型接入失败问题到底出在哪1.1 我最初的接入方案先交代任务场景。我这边每天要处理几百条项目日志来自不同的渠道格式五花八门有带时间的文本记录有半结构化的表格导出还有随手贴的 Markdown。以往全靠人工一条条拆字段、归类、入表一天要耗掉将近两个小时。我当时的想法很简单让模型来做这件事把非结构化日志整理成结构化表单省下重复劳动。技术方案上我选了最直接的路线写一个 Python 脚本循环读取日志文件把内容拼进一个固定的 prompt 模板然后调用模型的 API把返回结果解析成 JSON 后写入数据库。现在回头看这个方案从第一天起就埋着三个隐患第一prompt 里既堆了任务说明又堆了业务规则又堆了待处理日志所有东西混在一个超长字符串里第二没有做任何输出格式的硬约束完全指望模型自觉返回合法 JSON第三没有异常处理和重试机制模型一旦返回异常结果脚本就直接崩。我还特意对比了几种接入方式包括直接调 API、用某个开源框架封装、以及后来用的 WorkBuddy Skill。但当时觉得直接写脚本最简单就一头扎了进去。结果证明最简单的方案往往是最脆弱的方案。1.2 三个翻车现场第一版上线后我盯着跑了不到半天接连撞上三个典型问题个个都让我头大。第一个是输出格式随机漂移。同样的输入模型前一条返回的是规规矩矩的 JSON下一条可能就变成带着解释文字的 Markdown 代码块再下一条甚至把字段名从record_time改成了RecordTime。解析脚本是按固定字段写的字段名一变就抛 KeyError整个任务中断。最多次数的字段名变化一天之内出现了七种写法。第二个是上下文一长就失忆。我把 50 条日志一次性塞进 prompt模型在处理前面几条时还很正常到后面就开始丢信息——要么漏掉几条日志要么把前面已经归好类的记录复制一遍凑数。我一开始以为是模型理解能力不行后来查了上下文窗口才发现50 条日志加上任务说明token 已经逼近模型的上限模型在长上下文中的注意力衰减是必然的。第三个是同样的请求结果时好时坏。这个最让人崩溃。同一份输入上午跑是正常的下午跑就开始夹带私货甚至出现过连续返回十几条相同内容的死循环式输出。后来才意识到这是温度参数设得太高模型在采样时的不确定性被放大了。1.3 逐层定位根因是接入架构不是模型能力翻车之后我花了整整两天做定位。排查链路是这样的先写了一个最小化的单测脚本固定输入、固定参数单独调一次模型 API发现模型单次调用的逻辑其实是正确的——它能理解任务也能给出基本符合要求的输出。然后我把输入规模从 50 条降到 10 条再降到 5 条发现只要 prompt 短、输出要求明确模型的稳定性就明显提升。这就说明问题不在模型能力本身而在我这一侧的接入架构上下文管理缺失、提示词与业务参数混在一起、没有结构化输出约束和校验。换句话说我是在用裸调 API的方式去做一个本该有状态、有约束、有兜底的工程化任务。这个认知很关键。很多人一遇到模型表现不稳定第一反应是换更强的模型或者加提示词但真正的病根往往在接入层的设计上。模型是无状态的你每次调用都得把语境完整地喂进去如果你连喂多少、怎么喂、怎么校验输出都没想清楚换什么模型都一样翻车。2. 为什么选 WorkBuddy Skill三条路线的取舍2.1 三条路线对比定位清楚根因之后我面临一个选择怎么改当时摆在面前的有三条路线。第一条是继续堆代码。把脚本重构成完整的工程做上下文管理、写输出校验器、加重试机制、设计分块策略。这条路能走通但问题是每次改提示词、调参数都要改代码、走部署迭代成本很高。而且这些逻辑只对这个场景有效换个任务又得重写。第二条是换更强的模型。成本高不说关键是换模型并不能自动解决格式漂移和上下文管理问题——更强的模型照样会在长 prompt 下丢信息照样可能返回非 JSON 格式。我用另一个模型做了个快速实验同样的问题重现了七八成直接放弃。第三条是用 WorkBuddy 把模型封装成 Skill。WorkBuddy 本身是个 AI 工作台它的 Skill 机制恰好提供了一套声明式的封装方式把模型、指令模板、输入输出约束、工具接口、异常处理打包成一个独立模块。我不用自己写那套重试和校验的底层逻辑只需要在配置里声明清楚这个 Skill 要做什么、允许什么输入、必须返回什么格式。三条路线的对比我整理成了下面这个表对比维度继续堆代码换更强模型WorkBuddy Skill改动成本高每轮迭代都要改代码重新部署低但效果不保证低配置改动即时生效可复用性差每个场景单独写一套中模型可复用但逻辑不可复用高Skill 本身就是可复用模块稳定性控制靠手写校验器靠模型自身发挥配置层面有输出约束和兜底与 Agent 工作流结合需要额外开发需要额外开发原生支持可直接被 Agent 调用对比下来第三条路线在改动成本和可复用性上优势太明显了。而且它不排斥前两条路里的好东西——我照样可以在 Skill 里选一个合适的模型照样可以写自定义的校验逻辑只是这一切从代码逻辑变成了配置声明。2.2 Skill 到底帮我解决了什么WorkBuddy 的 Skill 机制本质上解决的是把模型能力工程化这个问题。我以前的理解是Skill 就是一个高级版提示词模板用下来才发现远远不止。它最核心的价值是做了四层封装。第一层是模型配置层模型名称、温度参数、最大 token、超时时间都放在配置里想调参数不用改代码改配置就行。第二层是指令模板层系统提示词和业务参数分离系统提示词负责定义你是一个什么角色、要遵守什么规则业务参数通过输入 schema 传入两者不混在一个字符串里。第三层是输入输出约束层Skill 会校验输入参数是否完整同时约束模型必须按照声明的输出格式返回不合规的输出会被拦截重试。第四层是工具接口层模型做不到的事比如查数据库、调外部接口可以声明成工具由工作台在模型需要时自动调用。这四层正好打在我翻车的四个痛点上。格式漂移有输出约束和解析校验兜着上下文管理有分块策略和 token 预算控制参数混乱通过输入 schema 解决异常情况有重试和降级机制。我不用从零搭建这套基础设施只需要专注设计这个 Skill 该怎么定义。2.3 第一版 Skill 的最小配置第一次用 WorkBuddy 创建 Skill我花了一个晚上搭出了最小可用版本。核心配置大致长这样skill: name: log_structurer description: 将项目日志整理为结构化记录输入原始日志文本输出 JSON 数组 model: provider: custom model_name: default-llm temperature: 0.2 max_tokens: 2048 timeout_ms: 30000 input_schema: source_text: type: string required: true description: 原始日志文本多条日志用换行分隔 fields: type: array required: false description: 需要提取的字段列表缺省使用默认字段 output_schema: type: json_array item_fields: - name: record_time type: string - name: category type: string - name: summary type: string - name: owner type: string system_prompt: | 你是一个日志整理助手。请将用户提供的日志逐条整理为 JSON 数组。 每条记录必须包含 record_time、category、summary、owner 四个字段。 不要输出任何解释文字只输出 JSON。如果某条日志缺少某个字段该字段填 null。 fallback: max_retries: 2 retry_interval_ms: 1000这个配置文件就是我第一版的全部内容。说实话当初写得非常粗糙system_prompt 只有三句话温度直接抄了网上推荐的 0.2输出约束也只定义了四个字段。但它至少把怎么调用模型从我的代码里抽了出来变成了一个可独立调整的模块。这为后面 15 轮迭代打下了基础——每一轮改动基本都是改配置、跑测试、看效果而不是重新编译部署脚本。3. 15轮迭代实录每一轮我改了什么、为什么改3.1 第 1~3 轮先把触发跑通第一轮迭代的目标不是让模型输出多完美而是让这个 Skill 能稳定地被触发、能正确接收输入、能返回一个可解析的结果。听起来简单实际操作中全是细节。第 1 轮我把 Skill 创建好之后第一个问题就是它的 description 写得太宽泛。WorkBuddy 的 Skill 触发机制里description 承担了路由的功能——Skill 会根据描述判断这个请求该不该由它来处理。我第一次写的 description 是处理文本结果什么请求都往这个 Skill 上撞连帮我算一下报销金额这种完全无关的任务都被路由过来了。这一轮我把 description 改成了将项目日志整理为结构化记录同时在 description 里加了两到三个关键词作为路由信号误触发率从开始的百分之四五十降到了个位数。第 2 轮我遇到的是输入参数校验问题。第一次测试时我故意少传了source_text这个必填字段WorkBuddy 默认的处理方式是让模型自己猜输入是什么。这其实是个坏设计——模型一旦开始猜输出就开始发散。我改成了在 schema 声明required: true并配置了缺参时的直接报错提示让 Skill 在入口处就把非法请求拦下来而不是指望模型兜底。第 3 轮核心是回滚和版本管理。我刚开始迭代时不注意保存每一版的配置有一次改乱了 system_prompt 想回退发现根本没有历史记录只能靠记忆重写。从第 3 轮开始我每次改动前都会导出一份当前配置存档命名规则是skill_日期_版本号。这个习惯在后面几轮帮了大忙——有好几次改坏了效果直接回滚到上一版几分钟就恢复。这三轮下来Skill 被触发、被调用、被校验的基本链路已经通了。但它输出结果的准确率还不太行大概只有六成左右而且偶尔还是会冒出非 JSON 的内容。3.2 第 4~8 轮输出质量稳定下来接下去五轮重心全在输出质量上。我给自己定了一个验收标准连续跑 100 条日志解析失败率不能超过 2%字段完整率不能低于 95%。第 4 轮我给 system_prompt 加了一条硬约束只输出 JSON不要输出任何解释文字。并把output_schema的约束从建议改成强制。WorkBuddy 在配置里支持把输出约束设为严格模式模型一旦返回不符合 schema 的内容会被系统拦截并附带错误信息重试一次。这一条改动立竿见影非 JSON 输出的比例从之前的一成多降到了接近零。第 5 轮我把温度从 0.7 降到了 0.2。这个参数我在第一版就设过但当时对它的影响没有体感。直到连着跑了三批测试数据对比了 0.7、0.5、0.2 三组温度下的输出才发现温度对事实性整理类任务的影响远比想象中大。温度越高模型越倾向于发挥——措辞更丰富但也更容易把日志里没有的信息脑补出来。在整理类场景里我不需要它发挥只需要它忠实提取所以温度直接压到 0.2 以下。第 6 轮我重写了 system_prompt。上一版 prompt 是把任务说明和输出规则混在一起的我发现当 prompt 越混模型越容易在其中一条规则上失焦。我把它拆成了三层结构第一层定义角色第二层定义任务目标和处理步骤第三层定义输出格式和边界情况处理比如字段缺失时填 null。三层之间用空行和序号隔开模型对规则的遵循度明显提升。第 7 轮处理上下文窗口问题。我的原始方案是把 50 条日志一次性塞进 prompt实测在模型处理到第 30 条左右时前文的信息开始丢失。我重新算了一笔账我的默认模型上下文窗口是 8K tokensystem_prompt 大约占 500 token输出预留 2K token真正能用来承载输入的只有大约 5.5K token。而每条日志平均约 180 token再加上分隔符等开销单次输入最多放 30 条日志。于是我把输入策略改成了分块每 25 条日志为一个 block逐块调用 Skill最后在代码侧合并结果。实测下来这个策略不仅解决了失忆问题还把并发度提高了三倍——反正块与块之间没有依赖可以并行处理。第 8 轮我在合并场景下又发现了一个新问题分块处理会把同一个项目的信息拆散导致category字段归类不一致。比如同一批日志里的需求评审第一块被归到任务第二块被归到会议。这属于典型的局部最优不等于全局最优。我的解决办法是把第一批处理的统计结果已出现的 category 集合作为参考信息在后续块调用时追加进 system_prompt 的末尾让模型在归类时参考前文的归类习惯。加了这一步之后字段一致性从 78% 提升到了 96% 左右。从第 4 轮到第 8 轮是我在 15 轮迭代里体感最明显的一段时间。每一轮改动的方向都不一样但验收指标是同一个连续跑 100 条日志的解析失败率和字段完整率。到第 8 轮结束时这两个指标已经达到了我定的验收线。3.3 第 9~12 轮错误恢复与兜底输出质量稳下来之后我开始处理意外情况。前面几轮测试数据都是我精挑细选的但真实日志远比测试数据脏有空行、有乱码、有条目被截断。这部分如果处理不好前面辛苦建立的稳定性会瞬间崩塌。第 9 轮配置超时和重试。真实调用中模型 API 偶尔会慢默认 30 秒超时在一个高峰期只跑到一半就触发了。我把超时从 30 秒调到了 60 秒同时在 fallback 配置里加了max_retries: 2重试间隔 1 秒。这里有个细节重试必须设置退避间隔否则模型服务端还在拥塞时瞬间重试只会加重拥塞。我把重试间隔做了个简单递增第一次 1 秒、第二次 3 秒。第 10 轮解析失败自动重试。有些时候模型返回的内容本身是合法 JSON但结构不对比如缺了字段或字段类型错了。这种情况靠返回非 JSON 就重试是拦不住的。我在 WorkBuddy 里配置了一个自定义校验器解析 JSON 成功之后再检查每个 item 是否包含record_time、category、summary、owner四个字段缺任何一个都判定为校验失败触发一次带错误信息的重试。重试时会把这个错误信息回传给模型告诉它你上次的输出缺了什么模型基本都能自我修正。第 11 轮增加高危操作的确认机制。这里得说个翻车事故有一次我加了自动写入数据库的流程某条日志被模型错误地归类到了已清理这一类结果直接把一条还没处理完的任务标记成已完成。如果不是及时发现这条任务可能就漏掉了。这让我意识到有些操作的代价比输出格式错误高得多不能全自动。我在 Skill 的输出里额外加了一个confidence字段让模型对自己每条归类的置信度打分。低于 0.7 的记录不进数据库而是进一个人工复核队列。代价是每天多了十几条需要人工看一眼的记录但换来了关键数据的可靠性。第 12 轮降级策略。不管怎么调模型总有小概率在多次重试后仍然失败。我不能让整个自动化流程卡住所以在 fallback 里配置了降级模式如果同一个 block 连续重试 3 次仍失败就把原始日志原样保留在待处理队列里同时给管理员发一条通知而不是直接丢弃。这个设计很朴素但非常重要——它保证了我的流程永远不会因为模型抖动而中断最坏的情况只是这一批留待人工处理。到这轮结束Skill 的稳定性已经从大多数时候正常提升到了异常情况有预案。自动跑了一周真正触发降级模式的只有两次都是模型服务端短时不可用造成的重试和降级都按预期工作了。3.4 第 13~15 轮性能与成本收口最后三轮我盯的是性能和成本。模型调用是按 token 计费的前面为了稳定性做了分块、重试、参考信息注入每一招都在增加 token 消耗。如果不收口每天的成本会比最初裸调方案高出三四倍。第 13 轮我重新梳理了 system_prompt删掉了所有冗余表达。原版 system_prompt 里有不少请务必非常重要这类语气词实际上对模型约束没有帮助反而每个字都在烧 token。精简之后system_prompt 从 500 token 降到了 320 token别小看这 180 token,乘以每天的调用次数一个月能省出一笔可观的费用。同时我调整了分块大小从每块 25 条提到 28 条——这是因为精简 prompt 之后输入侧的预算空间多了可以多塞一点日志减少调用总次数。第 14 轮加缓存。日志整理这个场景有个特点同一批历史日志如果参数没变结果应该是确定的。我给 Skill 加了一层简单缓存以输入文本的哈希值 字段配置版本号作为 key命中缓存就直接返回上次结果不再调用模型。跑了一周缓存命中率大概在 15% 左右。这个数字不算高因为大部分是新日志但用于历史数据回刷和测试场景非常划算——一次回刷就是上千条日志缓存命中能省掉大半调用。第 15 轮把日志和监控补齐。我在 Skill 的处理流程里加了一个轻量的结构化日志每次调用记录输入长度、模型返回耗时、token 用量、是否重试、是否降级、结果校验是否一次通过。有了这些数据我可以看到每天的成功率趋势、平均耗时、token 消耗分布一旦某个指标异常能立刻定位是哪一轮改动引起的。第 15 轮之后这个 Skill 正式进入了稳定运行阶段日处理日志 400~600 条解析成功率 99.3%平均每条日志处理耗时 1.2 秒每天需要人工复核的记录不超过 20 条。4. 20天踩坑浓缩边界条件与通用经验4.1 温度参数不是越大越好这次迭代让我对温度参数有了非常具体的认知。在整理、抽取、归类这类信息保真型任务里温度调高的收益几乎为零风险却很高——模型会在措辞上自由发挥甚至脑补出不存在的细节。我的建议是先默认 0.2 左右跑一批测试数据如果发现模型输出过于机械或重复再微调到 0.3~0.4如果你发现模型输出开始飘出现一些你不确定的表述优先怀疑温度是不是偏高了。生成创作类任务才需要更高的温度不要一套参数打天下。4.2 重试策略要有损很多人设计重试机制时容易陷入无限重试直到成功的误区。我在第 9 轮就踩过这个坑把重试次数设成 5 次结果有一次模型服务端故障持续了十几分钟同一个 block 反复触发重试既浪费了 token 又拖慢了整个队列。后来我把重试策略改成有损的最多重试 3 次每次退避时间递增3 次仍失败就降级到人工处理队列。核心思路是快失败、早兜底而不是死磕一个局部问题。模型服务端的抖动是常态你的流程必须能优雅地接受这种抖动而不是试图消灭它。4.3 Skill 与 Agent 的分工边界最后聊聊 Skill 和 Agent 的区别。这次做完之后我对这两者的分工有了更清晰的认识Agent 是决策者负责理解用户目标、拆解任务、决定调用哪些能力Skill 是执行者负责把某一个具体能力做深做稳。我在 WorkBuddy 里的用法是Agent 负责接收需求、判断要处理哪些日志、决定调用顺序log_structurer这个 Skill 负责把一段日志整理成结构化记录。Skill 不需要理解全局目标它只需要在自己这一亩三分地里做到稳定、可控、输出一致。反过来Agent 也不需要关心日志里有哪些字段、输出校验规则是什么这些细节全部封装在 Skill 内部。这个边界清晰之后最大的好处是职责单一改起来快。比如我想调整输出字段只需要改 Skill 的 schema 和 system_promptAgent 侧完全不用动我想让 Agent 多一个自动发周报的能力新增一个 Skill 就行不影响已有流程。如果你在做 Agent 时发现逻辑越来越乱可以先停下来审视一下是不是把太多本应该封装成 Skill 的细节直接堆在了 Agent 的提示词里。这 20 天的迭代下来我最大的体会是模型接入翻车不可怕可怕的是翻车之后把所有原因都归咎于模型不行。大多数时候问题出在接入层的设计——上下文怎么管、输出怎么约束、异常怎么兜底。WorkBuddy 的 Skill 机制恰好把这些工程化问题变成了配置问题让我能把精力花在真正需要思考的地方业务规则定义、边界条件设计、验收指标设定。如果你也在折腾类似的模型接入建议你也试试先封装成 Skill再逐步迭代这条路而不是一上来就埋头写调用代码。