- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 为什么现在要关注 AgentKit
- AgentKit 如何改变团队的工作方式
- 为什么智能体评估比单一模型基准测试更重要
- 数据集、轨迹评分与提示词优化是如何串联起来的
- 从实务角度看新的评估循环
- 面向产品团队的现实可行的推行清单
- 工程师、PM、平台团队各自需要关注的要点
- 结语
- 参考资料
为什么现在要关注 AgentKit
OpenAI 于 2025 年 10 月 6 日 公开了 AgentKit 页面，将构建、部署、优化智能体所需的工具整合成一套统一的流程加以呈现。按照官方说明，AgentKit 是 一套用于构建、部署、优化智能体的完整工具集，其中包含 Agent Builder、Connector Registry、ChatKit，并进一步加入了数据集、轨迹评分、自动提示词优化、第三方模型支持等能力。
重要的是，这一变化并不只是功能数量的增加。AgentKit 正式地把评估循环搭建在了 Responses API 与 Agents SDK 之上。如今团队能够更系统地管理的问题，已经从「智能体在演示里表现是否亮眼」转向了「在实际运营路径中，达成目标的稳定程度如何」。
这篇文章把重点放在实务而非营销话术上。内容整理得让工程师能够判断如何设计评估流水线，让 PM 能够判断该把哪些质量标准与产品 KPI 挂钩，让平台团队能够判断以什么顺序在组织内推行。
AgentKit 如何改变团队的工作方式
以往许多生成式 AI 项目都把重心过度放在模型选择和提示词撰写上。但智能体产品的性能并不取决于模型单次回答的好坏，而是由以下要素的组合决定的。
- 路由是否恰当
- 是否按正确的顺序调用了所需的工具
- 是否安全地处理了连接器权限与数据范围
- 失败时重试与备用路径是否正常运作
- 最终回答是否真正帮助用户完成了任务
AgentKit 改变的核心正在于此。它让团队不再只用一份提示词来谈论质量，而是 以产品为单位，衡量整条执行路径。如果说 Agent Builder 让设计与迭代变快，Connector Registry 管理外部系统连接，ChatKit 支撑用户体验层，那么新的评估功能则把这一整套都变成了一个可运营的系统。
换句话说，比起「好的模型回答」，AgentKit 更像是一套用来管理 「好的任务执行」 的工具集。
为什么智能体评估比单一模型基准测试更重要
单一模型的基准测试依然有用。摘要质量、代码生成准确度、推理性能等方面的比较，是模型选型的出发点。但对智能体产品而言，仅凭这些信息还不够。
原因在于，智能体的失败往往并非发生在模型本身，而是发生在 工作流的衔接点 上。
- 模型本可以生成恰当的答案，却可能选错了工具。
- 工具调用成功了，但中间状态传递有误，导致下一步走偏。
- 单次回答看起来合理，但整体执行时间过长，破坏了用户体验。
- 即使结果正确，一旦违反安全策略或审批流程，也无法真正上线部署。
因此，智能体的质量应当被视为比单一的「答对率」更宽泛的概念。在运营环境中，至少要能够回答以下问题。
- 失败集中在哪类任务上
- 失败的原因是模型回答、工具使用，还是上下文构成
- 修复之后，同类失败是否真的减少了
- 成本、延迟、成功率之间的平衡是否有所改善
AgentKit 的新评估工作流，正是把重点放在把这些问题量化上。这一点，正是它与单一模型测试最大的区别。
数据集、轨迹评分与提示词优化是如何串联起来的
许多团队在看这些评估功能时，倾向于把每个功能分开理解。但在实际运营中，把这三项功能看作一个循环会实用得多。
1. 数据集定义了什么才算做得好
数据集不是一堆例子的简单集合。一份好的智能体数据集，应当包含以下内容。
- 与真实用户请求相似的代表性场景
- 高价值任务，以及失败代价高昂的任务
- 模糊请求、信息缺失、权限限制等边界情形
- 成功标准明确的预期结果或评分规则
关键在于，数据集不应是一张考验模型智力的试卷，而必须是 我们产品必须通过的一份工作合集。
2. 轨迹评分展示问题出在哪里
如果只看最终回答，最多只能知道「失败了」。轨迹评分把评估范围扩展到了中间步骤。
举例来说，下面这些问题就变得可以被回答了。
- 第一次工具选择是否恰当
- 是否充分读取了检索结果之后再决定下一步行动
- 是否存在不必要的重复调用
- 在访问敏感数据之前，是否经过了恰当的确认流程
这种方式的优势在于调试速度。团队不再只是看到「最终输出不好」这一个事实，而能够追踪到 失败发生的具体路径与步骤。在改进运行中的智能体时，这类信息带来的价值，往往比换一个模型更大。
3. 自动提示词优化提升改进速度
有了数据集和轨迹评分之后，就能更结构化地比较哪种指令真正提升了性能。自动提示词优化的作用，就是把这一过程加速到与团队的迭代速度相匹配。
这里有两条重要的运营原则。
- 优化必须始终结合具有代表性的数据集来看待。
- 必须确认分数的提升是否真正与产品目标相连。
如果一个提示词只是提高了特定数据集的分数，却破坏了真实的用户体验，那就算不上是好的改进。所以自动优化不应被理解为一个独立的功能，而应被理解为 建立在数据集与轨迹标准之上运作的一套优化引擎。
从实务角度看新的评估循环
产品团队引入 AgentKit 时，最现实的运营循环大致遵循下面这个顺序。
- 基于用户请求日志与目标任务，构建评估数据集。
- 以业务标准定义成功条件与失败条件。
- 收集智能体的执行轨迹，并为关键步骤设定评分标准。
- 对反复出现的失败模式进行分类。
- 调整提示词、工具描述、路由策略、模型配置。
- 用相同的数据集和评分标准重新评估。
- 只有在确认改进之后，才逐步扩大部署范围。
这个循环的优点在于，它留下的不是「感觉变好了」这种模糊的印象，而是 可复现的改进记录。工程团队能够掌握修改的依据，PM 能够明确上线标准，平台团队则能够建立起共通的运营标准。
面向产品团队的现实可行的推行清单
没有必要从一开始就一次性引入所有功能。按下面的顺序推进，可以降低失败的概率。
从一个高价值工作流开始
首先要做的，是不要试图一次性解决整个组织的问题。选择一个像客户支持摘要、销售调研、内部运营自动化这类结果容易衡量的单一流程。
检查要点如下。
- 使用频率是否足够高
- 人是否能轻松判断成功与失败
- 出错时能否控制影响范围
让数据集贴近实际运营
初期的数据集不需要做得多宏大。重要的是真实性和代表性。
- 收集最近用户请求中经常出现的案例。
- 把成功案例和失败案例都纳入进来。
- 务必包含含糊输入和信息缺失的案例。
- 打上与产品 KPI 相关联的标签。
举例来说，如果是支持自动化智能体，不应只看答对率，还要一并考察解决时间、追加提问的发生率、是否需要转交给人工处理等。
从最小单位开始建立轨迹评分标准
如果从一开始就为每个步骤都附加细致的打分，运营负担会变得沉重。不如先只抓住下面这些失败代价高的步骤。
- 工具选择是否正确
- 依据数据是否充分
- 是否遵守了权限与策略
- 传达给用户的最终行动指示是否安全
这样开始，既不会让评估设计变得过于复杂，又能获得调试上的价值。
搭配护栏使用自动提示词优化
自动优化很强大，但用错了方式，可能会对特定评估集产生过拟合。因此需要以下护栏。
- 把训练用和验证用的评估集分开。
- 同时关注成本与延迟时间。
- 单独确认安全性、策略、品牌语气等非功能性标准。
- 保留需要人工审核的发布环节。
让平台团队提供统一标准
当智能体扩散到多个团队时，一旦各团队各自制定评估标准，运营质量就会开始动摇。平台团队最好至少能提供以下共通资产。
- 数据集编写模板
- 轨迹评分标准示例
- 部署前的通过标准
- 成本与延迟时间的报告格式
- 失败案例存档
只有具备这套共通标准，AgentKit 的优势才能在组织层面不断积累。
工程师、PM、平台团队各自需要关注的要点
工程师
- 不要只看最终输出，要观察整个执行路径。
- 在设计工具调用与状态转移时，要考虑到可评估性。
- 修改之后用同一数据集重新验证，这个习惯很重要。
PM
- 要把评估分数与真实的产品 KPI 关联起来。
- 要区分「演示令人印象深刻」和「运营表现良好」。
- 要先定义清楚，哪些失败可以容忍，哪些失败绝不能容忍。
平台团队
- 要把评估资产作为共通基础设施来提供。
- 与其阻止各团队的实验，不如提供可比较的运营标准。
- 要把在 Responses API 与 Agents SDK 之上收集到的数据，整合进组织层面的质量体系。
结语
AgentKit 之所以重要，并不是因为它增加了一批带着新名字的功能。真正重要的是，它把「构建智能体」这件事，与「将其评估、改进到可部署水准」这件事，纳入了同一条流程。如果从实务角度解读 2025 年 10 月 6 日发布的 AgentKit 消息，核心与其说在于 Agent Builder 或 Connector Registry 这类组成要素本身，不如说在于它通过数据集、轨迹评分、自动提示词优化，让智能体的运营变得可以反复进行。
未来智能体产品的竞争力，很可能不会仅由模型选择来决定。哪个团队能构建出更好的评估集、更快理解失败路径、更安全地部署优化，将成为拉开差距的关键。AgentKit 正接近于这场运营竞争的起点。