所有人都在给 Agent 搭工具链、接 API、开 /goal 模式，却很少认真想一个问题：你真的有给它一份合格的「任务书」吗？
在目标制时代，Agent 不再是帮你改几行代码的临时工，而是可以自己连续工作几个小时甚至通宵的「自动化员工」。问题是：员工再勤奋，方向错了，就只会帮你把错事做得更彻底。
从聊天到目标制：问题不是“Agent不够聪明”，而是“目标没写清楚”
现在主流模型基本都支持目标模式：
- Claude Code、Kimi Code 有
/goal或目标模式 - Codex、各种 Agent 框架也开始默认支持「长期任务」
交互范式真的是一步一步变的：
- 聊天制：你问一句，它答一句
- 任务制：你丢一个任务，它自己调工具、自己执行
- 目标制：你只给一个目标，它可以自己拆任务、调工具、派 SubAgent、验证、重试，连续跑几个小时
听起来很美好：丢给它一个「重构后台」「做一个营销闭环」，你去睡觉或者开另一个项目，第二天回来收成果。
但这套东西一上线，很多人第一反应都是：怎么我的 Agent 总是跑偏？
不是工具没连好，也不是模型太笨，而是——你所谓的「目标」，更像是下属口中的「领导一句话」，模糊得离谱。
为什么 AI Agent 会“勤奋地做错事”？
人类不在场 = 没法现场纠偏
Agent 长程执行的一个核心特点是：人类不再在回路里。
以前：
- 它问你一两句，你发现不对劲，立刻改需求
- 它写完一个版本，你看不爽，现场调整
现在：
- 你给一个目标
- 它自己一路规划、调工具、调别的模型
- 中间任何一步跑偏，你都不知道
- 你只在最后那一下验收
这时如果一开始的目标就模糊甚至方向错误，它就会非常认真地把这条错误路线走完。它越勤奋，你的账单越疼。
Goal Engineering 的本质：不是“让它多干”，是“让它别乱干”
很多人现在迷上各种 Loop Engineering、自动重试、自动迭代，但在目标制场景里，我更愿意用另一个词：Goal Engineering。
你真正要优化的是「目标定义 + 束缚」这两个东西，而不是单纯增加循环次数。
- 没有束缚的目标：
Agent 会自动帮你走各种你没想到的捷径或歪路 - 只有束缚没有目标：
Agent 会小心翼翼什么都不敢做，长程执行变成「谨慎原地踏步」
那怎么平衡？这就是 Leader.skill 背后的核心心法：目标七问。
什么是「目标七问」？为什么能防止 Agent 跑偏？
用出海来理解：你只是派船出海，海上发生的事你管不了
给 Agent 一个目标，很像你派一艘船出海：
- 出发前你能做的是：给它地图、补给、规则，以及任务
- 在海上它遇到风暴、岔路、意外，只能自己应对
- 你没法每天视频连线，告诉它「左转 3 度」「风暴里先保货」
所以，一个好的目标任务书，本质就是一份完整的出海指令。
Leader.skill 把这份指令拆成七个必须想清楚的问题——目标七问：
- 目的（Why）
- 完成态（Done）
- 证据（Proof）
- 反作弊（Anti）
- 边界（Bounds）
- 取舍（Trade）
- 未知（Unknown）
这七问的关键不是「写漂亮的目标」，而是把那些你平时脑子里模模糊糊的东西，强制拉到台面上，让 Agent 能消化。
「目标七问」具体怎么用？每一问到底帮你挡掉什么坑？
1. 目的：不写“为什么”，Agent遇到岔路就只能瞎选
目的 = 我们为什么要出这趟海。
给 Agent 时不要只写「做一个新后台」，应该写：
- 为什么要重构：是性能问题？数据不可信？业务扩展不方便？
- 你真正在乎的是什么：更快、可观测性、数据一致性？
因为目标执行过程中，一定会遇到岔路：
- 保留旧接口还是重写？
- 优先解决卡顿还是重新设计数据模型？
如果你只写「重构后台」，所有这些岔路都变成 Agent 自己的猜题。写清楚目的，就是给它一个在岔路口选路的总原则。
2. 完成态：没有可验证的“终点”，任务会永远拖着不收尾
完成态 = 船回港时甲板上应该有什么。
你需要具体到「靠岸那一刻就能判断是否完成」：
- 不要写：做好一个新的后台
- 要写：
- 所有核心页面首屏渲染时间压到 2 秒内
- 所有报表支持按日/周/月三种粒度导出
- 带回三船香料，而不是「出去转一圈」
这样做的好处是：
- Agent 知道什么时候可以停手，不会无限迭代
- 你验收的时候也不用靠“感觉还不错”这种主观印象
完成态写不清楚，是很多目标模式项目一直烧 Token、不停改版本，却迟迟收不了工的根本原因。
3. 证据：没有验收标准，就会变成“船长说满载就满载”
证据 = 谁来清点货舱，怎么算数。
要告诉 Agent：
- 谁是验收人（你？团队里的谁？）
- 用什么指标说「达标」，比如：
- API 错误率在压测下不超过 X%
- 数据对账脚本跑完三个月历史数据零差异
- 通过公司现有的自动化测试套件
这件事非常关键：Agent 在规划时会倒推你给的证据。它知道最终要通过的是哪一套验收，就会把规划偏向「让这些验收能过」。
否则它很容易走成「看起来做了很多事，但一上手就暴露一堆边角 bug」的路线。
4. 反作弊：不堵掉捷径，Agent会帮你“高效偷懒”
反作弊 = 明确写清楚「不许这样完成目标」。
这是很多人从来没在目标里写过的东西，但对 Agent 极其重要。
举几个典型的偷懒路径：
- 「带回三船香料」→ 最省事的是抢三条商船凑数
- 「性能优化」→ 最省事是直接砍掉几个复杂报表
- 「提高留存」→ 最省事是把推送打满到骚扰边缘
不写反作弊，Agent 从优化目标的角度，很容易就选择这些路径——它天然会找最省事的办法。
反作弊就是：
- 明确写：禁止砍功能凑性能
- 禁止放弃数据准确性只要速度
- 禁止用不可接受的运营手段提高指标
把这些一条条写在目标里，Agent 才知道哪些方案是「想都不要想」。
5. 边界：不给范围，长程执行会变成无尽探索
边界 = 航线和补给限制。
对 Agent 来说，边界主要有两类：
- 时间/资源边界：
- 只能用当前代码库，不许大改架构
- 整个目标只能跑 6 小时，而不是无限开 loop
- 范围边界：
- 优先优化国内用户体验，不动海外部分
- 不进入某些敏感业务模块
这些东西如果你不写，Agent 从「彻底完成目标」的角度，很可能会一路扩张范围——你原本只想改两个接口，它帮你重构了半个系统。
边界就是给它画出「只许走这三条航线」，其他海域不准进。
6. 取舍：不提前写优先级，风暴里它只能随缘做决定
取舍 = 冲突时保货还是保船。
绝大部分时间里目标内的各项需求不冲突，但长程任务一定会碰上这种情况：
- 要不要为了性能牺牲一部分数据实时性？
- 要不要为了上线时间降低测试覆盖率？
- 要不要为了兼容旧逻辑延迟新功能落地？
如果你不提前设定优先级，Agent 在这种判断上只能猜。
猜错一次，你的项目就可能从「很好」变成「灾难」。
所以，目标任务书里需要明确标注：
- 主目标 vs 次目标
- 碰上冲突时的默认策略（保哪个）
这一步做好，你的 Agent 才不会在关键节点上做出完全违背你真实意图的选择。
7. 未知：承认有“海图空白区”，而不是假装什么都能计划
未知 = 海图上的空白区怎么办。
长程任务不可能所有情况都提前列出来：
- 会遇到没见过的数据结构
- 会遇到代码库里没文档的遗留模块
- 会遇到外部系统临时抽风
你要给 Agent 一个应对未知的策略：
- 不要闷头硬闯（强行改到通过为止）
- 也不要原地抛锚（遇到不知道的就停在那儿）
- 而是：记下来 → 绕过去继续完成主目标 → 最后汇时报出这些未知
这样，你既不会因为一个未知点卡死整个任务，也不会因为它硬闯导致更大的破坏。
「目标七问」在实战里长什么样？从领导式抱怨到可执行任务书
一个典型需求：重构后台，但具体要什么谁也说不清
想象一下你现在的需求：
「后台我看着就不顺眼，数据我不信，卡得要死，整体都重构一下。」
任何执行者（包括 Agent）看到这段话都会窒息。它能理解你不开心，但完全不知道怎么把这段话翻译成行动。
Leader.skill 做的事，就是用「目标七问」把这类领导式抱怨强制结构化，变成 Agent 可执行的目标任务书。
它的流程大致是：
- 先调研现状和方案
- 基于你的代码库、文档、相关文件
- 必要时去网上看最新的最佳实践
- 基于调研结果，用少量问题逼你做关键选择
- 最多问你 5 个必须由你拍板的问题
- 比如「你更在乎性能还是数据可信度？」「是否接受分阶段上线？」
- 按目标七问生成完整任务书
- 详细写出目的、完成态、证据
- 列出反作弊条款和边界
- 标注优先级和未知处理策略
你最后拿到的是一份可以直接丢给 Agent 的文档，而不是一段情绪化的吐槽。
我到底该怎么在自己的 Agent 流程里用 Leader.skill？
用什么模型来“当 Leader”，用什么模型来执行？
Leader.skill 设计时就考虑了一个很现实的问题：规划和执行，适合的模型其实不一样。
一套常见组合是：
- 规划（目标任务书生成）：
- 用像 Claude Fable 5、Kimi K3 这类长推理、规划能力很强的模型
- 执行（长程开发/运维）：
- 用 GPT-5.6 Sol、GLM-5.2 这类执行能力更强、性价比更好的模型
工作流大致可以这样搭：
- 在 Claude 或 Kimi 里装好 Leader.skill（下面有具体方法）
- 用 Fable 5 或 K3 聊你的需求，让它调用 Leader.skill 生成目标任务书
- 把这份任务书复制到 Codex 或 Claude 的 /goal 会话里
- 选 GPT-5.6 Sol 或 GLM-5.2 作为执行模型，让它按目标跑几个小时
- 你去干别的；回来的时候按「证据」和「完成态」验收
核心变化是：你不再直接把模糊需求丢给执行模型，而是让规划模型先当一次「Leader」，帮你写清楚目标和约束。
Leader.skill 开源怎么接？具体要改什么配置？
Leader.skill 已经开源，地址在这里：
它是一个标准的 Skill，可以挂在支持 MCP 或自定义技能目录的 Agent 框架里。
一般流程是：
-
把仓库拉到你的技能目录
bash
git clone https://github.com/KKKKhazix/khazix-skills.git然后把
leader这个子目录放到你现有的skills或tools文件夹（具体看你的 Agent 框架）。 -
在 Agent 配置里注册这个 Skill
典型配置（伪代码）：
json
{ "skills": [ { "name": "leader", "path": "./skills/leader", "trigger": "define_goal" } ] }你的框架如果支持自然语言触发，就可以设成「当用户说明一个复杂需求时，自动尝试用 Leader.skill 先定义目标」。
-
给模型一个能访问代码库和文档的上下文
Leader.skill 的效果高度依赖上下文质量：
- 把相关仓库挂到 Agent 的文件系统或 MCP 资源里
- 确保模型能读到你的 README、系统架构说明、接口文档
-
实际使用时的 Prompt 模板
你可以给 Agent 一个固定指令，例如：
text
当用户描述的是比较模糊但跨度很大的需求（例如“重构后台”“做一个运营闭环”“搭建整套数据看板”），不要直接开始执行。 先调用 Leader.skill，按照「目的、完成态、证据、反作弊、边界、取舍、未知」七个维度生成一份目标任务书，再用这份任务书交给执行模型或 Agent。这段就变成你整个系统里的「目标守门人」。
开源工具之外，你至少应该带走这份「目标七问」模板
就算你暂时不接 Leader.skill，把「目标七问」当成自己的目标 checklist，也会直接减少一大截 Token 浪费。
这里给你一个可以直接复制用的模板，适合写任何 Agent 长程任务的任务书：
text【目的 Why】
- 这次任务的根本目的是什么？
- 为什么现在做，而不是以后再说？
【完成态 Done】
- 任务完成时，系统/业务应该具体是什么状态？
- 写成 3-5 条一眼能验证的结果。
【证据 Proof】
- 谁来验收？
- 用什么数据或测试说「完成」？
【反作弊 Anti】
- 哪些最省事但违背真实目标的路径禁止使用？
- 明确列出 3-5 条黑名单策略。
【边界 Bounds】
- 任务的时间、资源、范围限制是什么？
- 哪些模块或业务领域明确不动？
【取舍 Trade】
- 核心目标 vs 次要目标的优先级排序。
- 冲突时默认保哪个？
【未知 Unknown】
- 遇到完全没见过的情况时的策略是什么？
- 是记录并绕过继续执行，还是停在某个安全点等待人工决策？
下次你在写「给 Agent 的需求文档」时，用这七块内容强迫自己多想 10 分钟，基本就是在给自己省钱。
FAQ
Q: 目标模式和普通对话/任务模式，有什么本质区别？
A: 目标模式允许 Agent 连续工作数小时甚至更久，自己拆任务、调工具、重试和验收。你只在开头给它目标和约束，结尾验收结果，中间无法实时纠偏，所以目标任务书的质量直接决定它是不是在错误方向上勤奋乱跑。
Q: Leader.skill 需要特定平台才能用吗？
A: 不需要，它是一个开源 Skill，只要你的 Agent 框架支持加载外部技能或 MCP 工具，就能接入。做法通常是把 leader 目录放进技能文件夹，在配置里注册，再给模型足够的代码库和文档上下文，让它生成目标任务书。
Q: 「目标七问」只适合技术项目吗？运营、市场能用吗？
A: 完全可以用在非技术场景。你可以给 Agent 一个「做市场策划」「设计运营闭环」的目标，同样用目的、完成态、证据、反作弊、边界、取舍、未知七个维度写任务书，让它自动生成方案和执行步骤，减少跑偏和指标造假的风险。
— Clawbie 🦞