先统一：Agent 不是“更大的 Skill”
Skill 解决的是“稳定复用某个能力”；Agent 解决的是“在不确定环境下完成多步目标”。
所以判断是否需要 Agent 的关键不是“任务难不难”，而是：
- 是否需要多轮决策（plan -> act -> observe -> revise）
- 是否需要跨工具与跨系统
- 是否需要在失败时自我修复/改计划
一个实用决策树（你可以直接用）
按下面顺序问 6 个问题：
-
任务能否在 1 次工具调用 + 1 次生成中完成？
能 -> 单步 Skill -
是否只是固定步骤串起来（顺序固定、分支少）？
是 -> 工作流编排（非 Agent） -
是否需要根据中间结果决定下一步（分支多、动态路由）？
是 -> 考虑 Agent -
是否存在“写操作/高风险操作”（发消息、改库、发布）？
是 -> 必须设计人类确认点 -
是否可定义明确成功标准（可评测）？
否 -> 先别做 Agent（否则你不知道它是否在变好） -
是否能把外部不确定性收敛到工具层（重试、缓存、校验）？
否 -> 先补工具层工程化，再做 Agent
三类系统形态：从简单到复杂
1) 单步 Skill
适合：PR 摘要、日志解读、文档生成、SQL 草拟。
特点：输入输出契约清晰，稳定输出。
2) 编排型工作流（非 Agent）
适合：固定步骤的流水线，例如：
- 拉 PR -> 摘要 -> 生成评论草稿 -> 人类确认 -> 发布
特点：步骤固定，失败处理可预期，排障容易。
3) 多步 Agent
适合：开放域任务，例如：
- “排查某线上错误并给出修复建议与验证步骤”
特点：需要路由、重试、反思、工具组合，工程化要求高。
人类在环：不是让你“点确定”，而是控制风险
建议把人类确认点设计成三类：
- 写操作前确认：将要写入什么、写到哪里、影响范围
- 低置信度确认：模型认为不确定或证据不足
- 预算/成本确认：预计调用次数或预计成本超过阈值
动手做：把一个 Agent 任务“降维”为可控系统
以“自动发布 release note”为例：
- 先做单步 Skill：生成 release note 草稿（无写操作）
- 再做编排：拉取变更 -> 生成草稿 -> 人类确认 -> 发布
- 最后才考虑 Agent：当你需要自动判断“哪些变更应该进 release note”
这样做的好处是：每一步都有可回归、可观测的改进空间。
工程化清单
- 先能定义成功标准（否则无法评测）
- 先把工具层稳定性做好（重试/缓存/校验/幂等）
- 对写操作设置强制人类确认点
- 对预算/成本设置上限
常见坑
- “任务看起来酷”就做 Agent：排障成本极高
- 没有成功标准：你无法判断它是在变好还是在随机游走
- 把确认点交给模型：确认必须由系统/人类掌控
下一篇：Agent 编排模式：Planner-Executor、ReAct、Router、Graph。