先用通用 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，把复杂流程沉淀为可运行、可恢复的 Harness，把结果质量沉淀为 Eval 体系，最终形成一个可观测、可审计、可回滚的 AI 协作系统。
因此，“通用 Agent 还是自建 Agent”不是一道只能二选一的题。通用 Agent 是探索和执行入口，Skill、Tool、Schema、Harness、Policy、Eval 与 Governance 是按真实缺口逐步形成的工程资产；当这些资产需要独立运行时、长期状态和更严格的控制边界时，自建 Agent 系统才成为合理结果。
参考资料
