/goal 只是八分之一：Intent Engineering 完整框架

/goal 的边界：2/8

2026 年 4 月 30 日，OpenAI 在 Codex CLI 推出 /goal。5 月 12 日，Anthropic 在 Claude Code 跟进。两者都允许设置可衡量的完成条件，Agent 自主运行直到达成。

但 Paweł Huryn 指出：/goal 只覆盖了 Intent Engineering 框架的 2/8——Objective（目标）和 Desired Outcomes（期望结果）。其余六个部分仍然需要你亲自构建。

Huryn 自 2024 年起就倡导「像领导人类一样领导 Agent」，并在 2026 年 1 月正式提出八部分框架。

八部分 Intent Engineering 框架

部分	说明	/goal 覆盖？
1. Strategy	愿景、市场、价值主张、权衡、增长	❌
2. Objective	问题是什么，为什么重要	✅
3. Desired Outcomes	可衡量的成功状态	✅
4. Health Metrics	追求结果时什么不能退化	❌
5. Org Context	Agent 所处的系统和组织环境	❌
6. Constraints	转向提示 vs 硬护栏	❌
7. Autonomy Boundaries	哪些决策 Agent 可独立做，哪些需升级	❌
8. Stop Rules	何时停止、升级或完成	❌（仅覆盖 complete）

/goal 能做什么

Codex CLI v0.128.0：

/goal + /goal status + /goal pause + /goal resume + /goal clear
Agent 自行计划、执行、测试、审查每一步
GPT-5.5 sub-agent 检查工作
运行直到目标达成或 token 预算耗尽

Claude Code v2.1.139：

/goal <condition>
每轮后由轻量模型（默认 Haiku）检查 yes/no 并给出理由
支持 interactive、-p 和 Remote Control 模式
Hooks 正常触发

用法示例：

/goal all tests pass and lint is clean
/goal ship the auth flow without breaking existing sessions

第一个是字面任务锁定，第二个是意图锁定。两者都有效，但第二个在模糊性中存活。

这是真正的进步。也是 /goal 停止的地方。

Part 1：Strategy（策略）

策略是大多数 Agent spec 跳过的关键层：愿景、市场、价值主张、权衡、增长。

它来自你的业务，不是 Agent。但 Agent 需要它。策略塑造了 Agent 应该做出的权衡。这些都不在你的 CLAUDE.md / AGENTS.md 里。

行动：从你的 product strategy canvas 中提取三行放入 Agent 上下文。渐进式披露。

Part 2：Objective（目标）

目标命名问题并解释为什么重要。当指令用完时，它指导判断。

好的目标是：问题导向的、说明为什么重要、在模糊性下指导权衡。

弱："Handle customer support tickets."
强："Help customers resolve issues quickly without creating more frustration than they started with."

当你解释 why，Agent 就能推理边缘情况。

Anthropic 的 Teaching Claude Why 研究（2026-05-08）验证了这一点：学习对齐行为背后 why 的模型，比仅接受行为演示训练的模型能更好地处理新情况。

/goal 接受这类目标。有些团队传字面任务（"all tests pass"），有些传 why。后者在模糊性中存活。这就是 /goal 如何覆盖 Part 2。

Part 3：Desired Outcomes（期望结果）

将期望结果视为可观察的状态，而非 Agent 的活动。

规则：

可观察的状态，不是 Agent 活动
从用户视角，不是 Agent 视角
可衡量或可验证，不依赖 Agent 自报告
领先的，不是滞后的（可在执行期间或之后不久观察，不是几个月后）

支持 Agent 示例：

客户确认问题已解决
24 小时内同一主题无跟进工单
客户评价互动为有帮助

两到四个结果通常合适。更多意味着你在微观管理或不明确什么重要。

/goal 在平台层面强制执行这一纪律。如果你的结果不可衡量，evaluator 无法决定。平台迫使 spec 达标。

Part 4：Health Metrics（健康指标）

健康指标定义优化结果时什么不能退化。它们与 Part 3 配对：结果是你正在实现的，健康指标是你在实现过程中保护的。

古德哈特定律：当衡量成为目标，它就不再是好的衡量。

没有健康指标：

"更快解决问题" → Agent 赶工，质量下降
"提高吞吐量" → Agent 走捷径
"减少升级" → Agent 处理不该处理的事

健康指标主要指导 prompt 层，引导 Agent 在权衡时有多保守：

- CSAT 必须保持在 4.2 以上。如趋势下降，更保守。
- 重复联系率不得增加。优先解决质量。
- 升级质量分数必须稳定。不要为达标而少升级。

这与硬护栏不同，后者完全阻止行动。健康指标引导；护栏执行。

/goal 不建模这一层。你的 spec 需要。

Part 5：Org Context（组织上下文）

组织上下文描述 Agent 运作的世界。它解释 Agent 所处的位置，不是它能做什么。

包括：

系统上下文：其他 Agent、人类、工具、依赖
组织上下文：商业模式、用户、品牌

支持 Agent 示例：

System: 与人类 Tier-2 Agent 和自助知识库并肩工作。
升级进入人类队列，带完整上下文。
输出反馈工单系统和客户健康评分。

Organization: B2B 企业软件。
用户是时间压力下的非技术管理员。
品牌建立在可靠性上。

不是一切都进 prompt。核心上下文（始终需要）进 system prompt。参考上下文进 retrieval。动态上下文（每请求）进编排层。系统上下文可由编排自动注入。

/goal 不处理这些。

Part 6：Constraints（约束）—— 转向提示 vs 硬护栏

约束定义 Agent 不能做什么。两种形式，大多数人混淆。

转向提示（prompt-level）：

行为指导
风险偏好
语气和谨慎

它们影响推理但不强制执行合规。模型在压力下可以忽略。转向不约束，它只是建议。

硬护栏（orchestration-level）：

工具限制
输出验证
行动门控
审批门（human-in-the-loop）

如果约束重要，必须在架构中强制执行，不是语言中。示例：

不能发送外部邮件
不能修改账户设置
不能访问其他客户数据
不能承诺退款或法律结果

推理层提议。编排层执行。 如果约束只活在 prompt 里，它是 suggestion。如果违反不可接受，它必须活在 code 里。

/goal 在这里什么都不执行。Codex 和 Claude Code 都运行在你已配置的 sandbox 里。文件权限、网络规则、MCP 工具白名单。约束仍然是你的 wiring。

Part 7：Autonomy Boundaries（自主边界）

所有 Agent 行为可归为四种决策类型，每种携带不同风险：

完全自主：可逆行动、有限影响、充分理解的失败模式
** guarded 自主**：用户可见变更、中等风险。需要置信度阈值、日志、回滚能力
先提案：战略或敏感决策。Agent 提案 → 需要审批 → Agent 执行
无自主（需人类）：法律承诺、不可逆变更、财务行动、品牌承诺。Agent 分析推荐，人类执行

自主定义权限，不是停止条件。

正确的自主取决于谁承担风险。为自己构建 Agent 时，你吸收后果。将 Agent 构建进产品时：

用户可能不知道 Agent 行动了
用户无法评估 AI 生成输出
出问题时用户会责怪公司

规则：用户越不了解 Agent 在做什么，你的约束就需要越紧。

Part 8：Stop Rules（停止规则）

停止规则定义执行必须停止、升级或终止的时间。不指导权衡或决策质量。

Halt when:
- 检测到冲突约束
- 置信度连续两次低于最低值

Escalate when:
- 超出定义范围
- 检测到法律或合规主题
- 用户挫败持续

Complete when:
- 达成期望结果
- 用户确认解决

/goal 的自动继续覆盖了 complete 分支。但 "complete when outcomes achieved" 只是你的结果重新框定为停止条件。工作已经在 Part 3 中完成。

Halt 和 escalate 是承重分支，/goal 两者都不提供。当置信度下降、约束冲突、主题转向法律或合规时，Agent 必须知道停止而不是推进。这逻辑活在你的 hooks、置信度阈值和升级规则中。不在 slash 命令里。

明天早上做什么

打开 Agent 启动时读取的文件。当被给予 /goal 时，它如何发现：

Strategy：从你的 product strategy canvas 提取几行——愿景、市场细分、价值主张、权衡
Health metrics：Agent 追求目标时什么不能退化？命名两三个。如无法实时衡量，保持定性
Org context：两个块——系统（Agent 周围是什么）和组织（Agent 服务谁）
Constraints：分离转向提示（语气、谨慎、何时询问）和硬护栏（工具、hooks、sandbox 中强制执行什么）
Autonomy boundaries：哪些决策 Agent 可独立做？哪些需要审批？哪些需要人类？
Stop rules：Halt 条件（何时提前停止）、escalate 条件（何时移交）、complete 条件（你的结果，已在 /goal 中）

如果你能把 intent spec 交给另一个对你的产品知之甚少的人类，他们在压力下会做出相同决策，你的 Agent 才有机会。如果不能，它缺少从未进入文档的知识。

模型能力已经足够。区分生产环境可靠运行与静默失败的 Agent 的不是智能，而是清晰的 intent。

资源

Huryn 的 Intent Engineering 框架：productcompass.pm
Product Strategy Canvas：productcompass.pm
Anthropic Teaching Claude Why 研究：anthropic.com