先用通用 Agent，还是自己写 Agent？我的实践判断框架

最近我一直在想一个问题：

已经有 Codex、Claude Code 这类通用 Agent 了，我应该直接使用它们，还是为自己的工作再写一个 Agent？

一开始我很容易把“沉淀能力”理解成“做一个专属 Agent”。但随着真实工作逐渐变多，我发现这两个概念并不相等。很多时候，我真正缺的不是另一个 Agent，而是把已经验证过的业务知识、确定性动作、复杂流程和质量标准保存下来，让现有通用 Agent 下次还能稳定复用。

我的结论是：

默认先使用通用 Agent 完成真实工作；只有当稳定需求暴露出明确的运行时缺口时，再逐步补 Skill、Tool、Harness 和 Eval。不要把“自己写 Agent”当成能力沉淀的默认终点。

这篇文章真正想讲清楚的能力沉淀主线是：

把业务知识沉淀为可复用的 Skill，把专业动作沉淀为健壮的 Tool，把复杂流程沉淀为可运行、可恢复的 Harness，把结果质量沉淀为 Eval 体系，最终形成一个可观测、可审计、可回滚的 AI 协作系统。

这不是要求所有能力依次补齐固定层级，也不是一套行业标准“七层架构”。它是一条从真实工作出发的工程化路径：先由通用 Agent 验证问题和方法，再把真正稳定、反复出现的部分沉淀为对应资产。

一、先说清楚：“自己写 Agent”到底指什么

很多讨论把三件事混在了一起：

给通用 Agent 一套稳定的专业说明；
为 Agent 增加可调用的工具和固定工作流；
建设一个拥有独立运行时、状态、权限和评测的 Agent 系统。

第一种通常只是 Skill 或指令，第二种是“通用 Agent + Tool / Workflow”，只有第三种才更接近真正的自建 Agent 系统。它通常也不是重新训练一个模型，而是围绕现有模型建设执行循环、工具调用、状态管理、权限控制、恢复机制和质量评估。

OpenAI 的 Agents SDK 同样把 Agent 描述为配置了 instructions 和 tools 的模型，并由运行时管理工具调用、guardrails、sessions 与 tracing。也就是说，自建的主要工作往往发生在模型之外。

二、为什么我更倾向先用通用 Agent

真实业务刚开始时，通常有三个未知：

这个需求会不会再次出现；
真正稳定的步骤是什么；
哪些环节需要 AI 判断，哪些环节应该写成确定性程序。

如果此时马上建专属 Agent，很容易把一次性的操作顺序固化成架构。等第二次遇到类似问题，才发现输入不同、关键判断不同，之前设计的流程并不通用。

通用 Agent 更适合前期探索，因为它能和人一起阅读资料、补问题、执行工具、根据现场反馈调整步骤。这个阶段最重要的产物不是 Agent 代码，而是被真实任务验证过的工作方法。

Anthropic 在《Building effective agents》中也建议从最简单的方案开始，只在确实需要时增加复杂度：定义清楚的任务更适合可预测的 workflow，无法提前写死路径、需要模型动态决策的开放问题才更适合 Agent。

三、一次真实实践如何逐步暴露“该沉淀什么”

以测试数据场景构造为例。最初的需求并不是“请做一个测试数据 Agent”，而是：根据测试场景批量准备账号、关系和业务数据，并能确认最终状态正确。

第一次由通用 Agent 和人协作完成后，逐渐出现了不同类型的稳定内容：

反复出现的内容	更合适的沉淀形态	原因
场景拆解、风险判断、验收方法	Skill	保存专业 know-how，让通用 Agent 下次按相同方法工作
创建账号、建立关系、查询结果	Tool	输入输出明确，适合确定性执行和单独测试
场景、账号、状态之间的字段约定	Schema	让 Planner、Tool、状态和报告共享同一份横向契约
多步骤执行、检查点、停止、续跑和验收	Harness	管理完整运行生命周期，而不是只描述步骤
禁止使用生产环境、限制高风险动作	Policy	保存不可逾越的执行边界
AI 是否选对场景、工具和安全动作	Eval	衡量 AI 或完整系统完成任务的质量
版本、权限、证据、隐私和成熟度	Governance	管理资产的长期生命周期

这七个名称是我用于检查能力是否完整的审计维度，不是行业标准七层架构，也不是每项能力都必须补齐七份产物。

其中两个边界尤其重要：

Schema 是横向契约，不一定处在某个固定的“第三层”；
Observability、Audit、Security、Rollback 是横切保障，不能只写进 Governance 文档，必须由真实 Tool 或 Harness 落地。

四、什么时候只需要 Skill

如果问题主要是“通用 Agent 不知道我所在专业领域应该怎么做”，先写 Skill 往往已经足够。

适合只做 Skill 的信号包括：

任务主要依赖一套稳定的方法、检查清单或写作规范；
仍然需要人参与澄清和判断；
现有通用工具已经能完成大部分动作；
失败后重新对话或人工修正的成本很低；
当前目标是提高复用一致性，而不是无人值守运行。

例如，测试用例设计可以先把“先确认模块结构，再逐模块展开场景”的方法写成 Skill。它并不必然需要一个独立 Agent 服务。

五、什么时候该补 Tool 或 Workflow

当某个动作输入输出已经稳定，就不应继续让模型每次临场生成实现。

例如：

解析固定格式的测试规范；
调用业务 API 创建测试数据；
校验字段、计算哈希或生成报告；
从多个来源读取状态并做确定性比对。

这些动作更适合封装为 Tool，并用普通软件测试保证可靠性。

如果任务步骤固定、分支有限，也可以先使用确定性 Workflow。OpenAI 的实践指南指出，在复杂判断、难维护规则或大量非结构化数据等场景中 Agent 更有价值；如果用确定性方案就能解决，未必需要 Agent。它同时建议先最大化单 Agent 加工具的能力，再在复杂指令或工具选择持续失败时考虑拆分多个 Agent。

六、什么时候 Harness 才真正有价值

我曾经把“Adapter + Uploader + Verifier”理解为 Harness，后来发现这还不够。它们只是执行链上的组件。

真正的 Harness 至少需要回答：

从哪里开始，下一步由什么条件决定；
运行状态保存在哪里；
哪些阶段允许重试，哪些失败必须停止；
如何创建 checkpoint；
中断后如何恢复，并避免重复副作用；
哪些动作需要人工授权；
完成后如何验收和留下证据。

可以把它简单理解为：

Harness = Orchestration + Runtime + State + Recovery

当任务只是一次对话或几个可重做的小步骤时，Harness 可能是过度设计。当任务会跨多步、产生外部副作用、需要断点续跑或无人值守执行时，它才从“工程加分项”变成必要基础设施。

七、什么时候才值得建设自己的 Agent 系统

我现在使用下面这组问题判断：

判断问题	如果答案为“是”
任务会稳定、频繁地重复吗？	值得从对话中抽取正式资产
输入、输出和成功标准已经清楚吗？	可以建立 Schema、测试和 Eval
每次执行都需要模型动态决定下一步吗？	Agent 比纯 Workflow 更有价值
需要调用多个系统并管理长期状态吗？	需要运行时或 Harness
失败会产生重复数据、资金、权限或业务风险吗？	必须增加 Policy、授权、幂等与恢复
需要多人或长期维护吗？	需要版本、证据、可观测和治理
通用 Agent + Skill + Tool 仍然频繁失败吗？	才有充分理由增加专属编排或多 Agent

只有这些信号组合出现，且收益能够覆盖维护成本时，我才会选择自建。

八、不要用软件测试冒充 Agent Eval

还有一个很容易踩的坑：工具的单元测试全部通过，不代表 Agent 就完成得好。

应该至少分开三类证据：

软件测试：Tool、Schema、Harness 的代码是否按设计运行；
评分器基线：golden 样例能否证明 grader 会奖对、罚错；
真实 Eval：AI 面对代表性任务时，是否选对工具、覆盖关键边界、遵守安全规则并交付正确结果。

前两类是在验证基础设施，第三类才是在评价 Agent 或完整系统的任务质量。

九、我最终采用的递进路线

真实任务
  ↓
先由通用 Agent + 人协作完成
  ↓
复盘哪些知识、动作和流程真正稳定
  ↓
方法稳定 → Skill
动作稳定 → Tool
字段稳定 → Schema
多步运行需要状态与恢复 → Harness
存在不可越过的风险 → Policy
需要证明 AI 质量 → Eval
进入长期维护 → Governance

这条路线的重点不是把七项全部补齐，而是让每一次工程投入都来自真实缺口。

最终，我想实现的也不是“我写了很多 Agent”，而是把下面这条路径真正落地：

把业务知识沉淀为可复用的 Skill，把专业动作沉淀为健壮的 Tool，把复杂流程沉淀为可运行、可恢复的 Harness，把结果质量沉淀为 Eval 体系，最终形成一个可观测、可审计、可回滚的 AI 协作系统。

因此，“通用 Agent 还是自建 Agent”不是一道只能二选一的题。通用 Agent 是探索和执行入口，Skill、Tool、Schema、Harness、Policy、Eval 与 Governance 是按真实缺口逐步形成的工程资产；当这些资产需要独立运行时、长期状态和更严格的控制边界时，自建 Agent 系统才成为合理结果。