Agent 调优工程：如何把数字员工从「Demo」推进到「生产可用」
Agent 调优工程，是 FDE 把数字员工智能体从Demo推进到生产可用的关键工程。
我的同事佳新在布道 AI Workforce 的文章《FDE：用系统工程释放 AI 的工业革命级价值》中曾经提到，FDE 是对端到端结果负责的单一 owner，FDE 不只要能识别业务机会和沉淀能力，还要让数字员工能真正生产可用，并持续升级，最终实现业务再造。
本文把问题聚拢，专门讨论其中具体且关键的一环：Agent 调优工程。我们将从一次真实的长程 Agent 调优经历出发，解释为什么调优需要工程化，基准测试和多轮迭代应该怎样设计，以及 FDE 如何借助 AI 调优来达到持续运营的目标。
1. 为什么要有 Agent 调优工程
近期我们在某制造业客户落地 AI Workforce 时，需要构建一个架构设计智能体：读取业务上下文和需求，产出包含 ADR、架构图和时序图的架构文档。FDE 和业务方一起工作了没多久，智能体就构建完成了，它有 5 个阶段，会调用多个 Skill 和 SubAgent，会运行脚本，也会多次向用户确认和澄清。
但棘手的问题才刚刚出现。产出的架构图不符合业务要求：组件随意堆叠，内外部边界不清，模块交互关系错乱，系统层级未能正确体现；多次执行有时会不遵守既定流程：还没有完成现状分析就直接进入方案设计，架构决策尚未确认就开始画图，甚至跳过 Review 直接生成最终文档；运行时间久，长程任务稳定性差：有时运行到一半自己就停止了，有时会突然进入死循环。
Demo和生产的差别就在这里，同样都能走完流程生成产出物，但一个稳定可用，另一个不稳定也不可用。对于上述这些问题的调优，通常我们第一个想到的办法就是 “打补丁”，哪里不对补哪里，反正也是跟AI聊天，直接告诉它 “这里不能xxx，应该xxx”，5分钟就能出一个新版。这的确是一种朴素的调优办法，但和工程化调优不沾边。
第一，手工、随意的调优不可靠不可信。 如果只是凭感觉反复强调“严格按顺序执行”，下一次恰好没有跳步骤，也无法知道是改动真的生效，还是模型随机波动。调优必须有固定旧版、可重复任务、完整运行记录、单次变更假设和明确通过条件，才能回答“是否真的更稳定、为什么变好了、有没有影响到别的能力”。
第二，必须先找到问题属于哪一层。 智能体不按流程办事，可能是流程指令不清、阶段之间没有明确交接条件，也可能是主 agent 在子 agent 尚未结束时就关闭了会话。前者应修改 Skill Prompt，后者属于 Runtime Harness。
第三，调优是一件持续的事，而不是一锤子买卖。 业务规则会变，模型会不断升级或来回切换，触发、规划和工具使用行为也可能改变。今天通过的版本，半年后未必仍然适用。因此每个已上线 Agent 都需要保留回归测试集和版本记录，发生任何关键变化都应触发重新验证。
工程化的意义，是把“这次好像跑通了”变成一条可以复核的证据链。只有这条证据链成立，FDE 才能判断这次 Agent 真的被优化了。
2. 什么是 Agent 调优工程
Agent 调优工程，是围绕以 Skill、Plugin 等方式沉淀领域能力的 Agent 建立的持续改进机制。它把业务目标翻译成基准测试，通过真实执行候选版本，依据全链路 Trace 定位问题点，再触发修改Agent的描述、指令、脚本或验证规则等，最后用是否通过基准测试决定是否完成调优。
借助 Agent 调优工程，FDE 能够把业务流程和领域知识总结沉淀成可执行的契约，再用生产证据决定数字员工的能力边界。
这里需要区分 “Agent调优工程” 和 “Harness 工程” 的定义边界。简单来说，Agent 调优工程修改的是“数字员工会什么、怎样完成领域任务”：例如 Skill / Plugin 的触发描述、指令、Context、示例、领域 Workflow、Tool schema、脚本和验证规则。Harness 工程修改的是“数字员工在什么通用环境里运行”：例如会话管理、权限、Tool dispatch、SubAgent lifecycle、重试、Context compaction 和观测机制。
两者不能混在同一次测试中计算收益。若 Harness 发生变化，旧 Baseline 就失去可比性，需要在新环境中重跑；若 Trace 证明问题来自领域能力，那么再修改 Skill / Plugin。
另外，在正式开始 Agent 调优之前，我们应该意识到一个真正生产可用的 Agent 需要满足如下条件： - 质量：在典型任务和关键场景上达到目标，而不是只展示一次成功案例； - 安全：高风险动作有确定性约束，即使通过任何其他基准测试都不能放过一次严重错误； - 成本：Token、模型调用和工具成本在预算内； - 时延：在足够样本上统计执行时延和超时率满足业务 SLA； - 可观测：能看到输入、Skill 加载、Tool Call、SubAgent 和最终 Outcome 的完整 Trace； - 可治理：有版本管理、支持灰度，知道每次变更为什么发生； - 可恢复：发生故障时能够停止、降级或转人工。
3. Agent 调优工程怎么做
3.1 调优是一个 Loop
一轮完整调优包含八个动作：
- 先定义清楚什么是 “更好”，即基准测试
- 准备一组有代表性的测试任务
- 先跑旧版，记录当前表现作为 Baseline
- 查看运行记录，找到主要问题
- 基于有效性判断，选择&组合优化方法
- 做出一个或数个待测试的 Candidate
- 用同样的任务比较新旧版本
- 保留更好的版本，继续下一轮或停止
为了公平比较，新旧版本应该使用相同的模型、输入、工具权限和评分标准。每一轮也尽量只验证一个主要改动，避免同时修改很多地方，最后却不知道哪一项真正有效。
例如，面对前面提到的跳步骤问题，一轮实验可以这样描述：
看到的问题：部分任务没有 Review 记录，就直接生成了最终结果。
优化尝试：要求 Review 阶段生成完成标记，最终阶段开始前必须先检查这个标记。
判定失败：任何测试任务仍然跳过 Review，或者虽然不跳步，但预设错误没有被 Review 发现。
3.2 设定基准测试（Benchmark）
一个典型的基准测试可以是这样的：
| 要检查什么 | 要回答的问题 | 示例 |
|---|---|---|
| 最终产出物 | 任务是否真正完成 | 必需文件全部产生，下游能够继续工作 |
| 严重错误 | 哪些情况出现一次就不能接受 | 跳过审批、越权调用工具、缺少关键产物 |
| 结果质量 | 完成以后做得好不好 | 内容正确、依据完整、能够追溯到输入 |
| 办事过程 | 是否按要求完成必要步骤 | 先分析再设计，Review 通过后才能输出最终版 |
| 时间和成本 | 是否满足业务预算 | 在规定时间内完成，单次费用不超过上限 |
| 原有能力 | 新版本是否破坏旧功能 | 原有命令、文件格式和使用方式仍然有效 |
调优时最核心的对照只有两个：正在使用的旧版本和本轮新版本。两者使用同一批任务、同一个模型和相同环境重复运行，比较谁最终通过了全部基准测试，这样才能把变化归因到本轮修改。Anthropic 的 Agent Eval 实践与 OpenAI 的 Evaluation Flywheel也都强调重复执行、运行记录、失败分析和定向改进的组合。
3.3 六类调优方法
已经有很多论文、开源项目和工程实践讨论 Agent 调优，汇总下来我们归纳出六类调优方法：
| 方法 | 什么时候用 | 怎么做 |
|---|---|---|
| 人工诊断+控制变量 | 目标清楚，能大致定位问题所在的步骤或范围，但不知道问题具体出在哪里时 | 先确定测试和错误定义，之后每次只改一项，例如 Skill 描述，步骤，工具等；OpenAI Evaluation Flywheel就是这类受控迭代 |
| 多候选优选 | 改善类目标，在有限的维度上可能存在多种改善路径 | 一次生成多个不同的 Candidate，在同一组 Eval 上排名；是一种类似育种的规模化筛选方法。APE展示了这种思路 |
| 文本梯度反馈 | 有成功标准和足够的失败案例，可以由AI辅助归因 | 类似ML的梯度下降法，让模型基于失败案例归因，然后对当前版本生成批评文本，再据此改写；ProTeGi、TextGrad与 GEPA都提供了不同实现 |
| 竞争筛选搜索 | 当维度互相耦合，可选组合很多时，多候选枚举的方法行不通 | 以类似遗传筛选和搜索树的方式，对候选做变形、组合和分支探索，保留优胜，再逐轮淘汰；可参考 OPRO、PromptAgent与 Promptbreeder |
| 全链路优化 | 对于多阶段的复杂任务，单个阶段的优化效果不明显，需要端到端优化 | 用统一的端到端指标同时优化几个环节，避免局部优化全局劣化的问题；DSPy展示了如何把多阶段 LLM 程序作为整体优化 |
| 工作日志和自我提升 | 对于通用能力覆盖不到的个性化长尾需求，需要可插拔的优化 | 智能体通过反思的方式积累工作日志，把经过多次确认的失败变成经验，经验只适用于特定场景，不影响能力主体；可参考 Reflexion、ExpeL、Self-Refine 与 Voyager |
这些研究共同说明，自然语言指令、示例、工具调用和 Workflow 都可以成为可测试、可搜索的制品。与传统模型训练不同，Agent 调优会经常修改可读、可版本化的文件；因此每次修改不论是否通过基准测试，都应该留下父版本、记录动机和淘汰原因。
3.4 收敛边界
通常只要 Candidate 通过了基准测试即可认为优化完成，然而有时优化过程会难以收敛，例如对于运行速度提升20%的目标，可能无论怎么优化都只能达到15%，为了应对这种情况，需要明确优化的收敛边界。
一组实用的收敛边界可以是： - 成功通过基准测试 - 已达到最大尝试轮次 - 连续 N 轮的绝对收益都低于设定阈值 - 所有优化方法都已尝试过 - 成本或时延已达到临界点
这些边界设定必须在调优开始前写下来，运行中不能因为结果不好看就临时放宽。例如，可以约定至少运行 10 轮，连续 2 轮提升都低于 1% 时停止，同时设置总预算和最长运行时间。
另外，稳妥的方式是保留一组各有取舍的候选：有的版本更快，有的更便宜，有的在长 Context 下更稳定。最终版本由业务优先级选择。
4. 用 Agent 来调优 Agent
FDE 用 AI 赋能企业再造的同时，自己也应该以 AI Native 的方式工作。显然，前面所述的调优工程中，大量的执行工作可以完整交给 Agent 来驱动。
OpenAI 在《Building
self-improving tax agents with
Codex》中展示了其实践：把生产发现结构化为可复现问题，再交给 Coding
Agent 修改并最终通过测试验证。同样的，我们构建了面向调优 Claude Code
Plugin 的 plugin-tuner 将调优过程收敛为一个通用
Campaign：它接收用户目标、待优化的 Plugin 和 Eval Spec
作为输入参数，通过真实的 Claude Agent SDK Adapter 执行原版Plugin
与Candidate，记录
Trace，选择适合的调优方法，并持续迭代到收敛门禁通过。
plugin-tuner 的控制流： 
plugin-tuner 作为一种支持 FDE
工作的称手工具，它非常适合被集成在《FDE：用系统工程释放
AI 的工业革命级价值》中提到的 “FDE 工作台” 中。FDE
在客户现场积累的长期资产，是从业务目标、失败样本、调优决策到生产证据的完整链路。FDE
工作台将这条链路标准化后，每次交付都会为下一次同类工作留下可复用的
Benchmark、失败分类和调优策略。
总结
本文介绍了Agent 调优工程的概念，Agent 调优应该被视为是持续运营数字员工能力的必要手段。伴随着 AI 技术的快速发展，可以预见 Agent 调优工程也会是一种快速迭代的工程方法，期待今后能与各位读者持续讨论这一主题。