# OpenAI and Anthropic shipped /goal. Your agent still needs the other six.
**作者**: Paweł Huryn
**日期**: 2026-05-17T20:29:42.000Z
**来源**: [https://x.com/PawelHuryn/status/2056109927727292629](https://x.com/PawelHuryn/status/2056109927727292629)
---
Lead agents the way good orgs lead empowered teams. OKRs (2016) → empowered teams (2020) → intent engineering (2024). /goal is two of eight parts.
On April 30, OpenAI shipped /goal in Codex. On May 12, Anthropic shipped /goal in Claude Code. Both let you set a measurable completion condition. The agent runs autonomously until it's met.
I'd been writing about leading agents like humans since 2024. I formalized the eight-part framework in January 2026: strategy, risks, hard guardrails, autonomy boundaries, and four more. /goal is two of those eight parts.
## What /goal Does and How to Use It
Both labs shipped the same primitive. You set a measurable completion condition. The agent runs autonomously until it's met or it can't.
Codex CLI v0.128.0 added /goal on April 30, plus /goal status, /goal pause, /goal resume, and /goal clear. Claude Code v2.1.139 added /goal <condition> on May 12. Both run autonomously until an evaluator model says the condition is met.
Neither pauses cleanly for clarifying questions. I tested Claude Code v2.1.139 directly: set a goal requiring three user answers, then asked three questions. The Haiku evaluator fired after every agent turn without waiting for input, returning reasoning like "The user has not answered any of the three questions." Seven firings on one goal. No pause.
Codex has a question-asking tool that's supposed to pause for clarification, but in practice it self-loops generating ~150 duplicate questions in one run or hangs waiting for answers (openai/codex #21786, #23164). Forward-only autonomy is the default.
Usage:
```
/goal all tests pass and lint is clean
/goal ship the auth flow without breaking existing sessions
```
The first locks the literal task. The second pins the intent. Both work. The second survives ambiguity.
That's a real advance. It's also where /goal stops.
## Lead Agents Like Humans
You wouldn't onboard a senior PM with "handle customer support." You'd ground them in the strategy first: vision, market, value proposition, trade-offs. Then give them the objective, the outcomes that prove success, the org context they operate in, the metrics that must not degrade, the constraints, the decisions they can make alone, and when to escalate.
Agents need the same thing. Same structure, same parts.
The framework isn't new. The top layer is product strategy. Parts 2 and 3 are OKRs as defined by Christina Wodtke and team objectives by Marty Cagan:
- Meaningful problem to solve + Why
- Desired, measurable outcomes
Parts 4 through 8 are how empowered teams already operate inside that strategy. The move I made was applying all of it to agents.
Agents don't fail because the model is weak. They fail because intent is incomplete. Objectives are vague. Outcomes are implicit. Trade-offs are unstated. Constraints are treated as suggestions. Autonomy is granted without understanding risk.
/goal solves one slice of this. The agent now has a destination. It still has to decide how to get there. Which actions are reversible. Which need approval. What must not degrade along the way. When to halt instead of pushing through.
If those aren't specified, the agent invents them. Sometimes correctly. Often not.
## The Eight Parts of Intent
The eight parts:
1. Strategy. Vision, market, value proposition, trade-offs, growth.
2. Objective. The problem and why it matters.
3. Desired Outcomes. Measurable states that prove success.
4. Health Metrics. What must not degrade while pursuing outcomes.
5. Org Context. Where the agent sits. System and organization.
6. Constraints. Steering prompts and hard guardrails.
7. Autonomy Boundaries. Which calls the agent makes alone, which it escalates.
8. Stop Rules. When to halt, escalate, or complete.
/goal covers Parts 2 and 3, if you write the goal well. The other six are still yours.
## Part 1. Strategy (not in /goal)
Strategy is the key layer most agent specs skip: vision, market, value proposition, trade-offs, growth.
It comes from your business, not your agent. But the agent needs it. Strategy shapes the trade-offs the agent should make. None of it is in your CLAUDE.md / AGENTS.md.
The move: lift three lines from your product strategy canvas into your agent's context. Progressive disclosure.
## Part 2. Objective
The objective names the problem and why it matters. It guides judgment when instructions run out.
A good objective is problem-focused, says why it matters, and guides trade-offs under ambiguity.
Weak: "Handle customer support tickets." Better: "Help customers resolve issues quickly without creating more frustration than they started with."
When you explain the why, the agent can reason about edge cases.
> Anthropic's Teaching Claude Why research (May 8, 2026) validated this on the training side: models that learn the why behind aligned actions handle novel situations far better than models trained on behavior demonstrations alone.
/goal accepts this kind of objective. Some teams pass it the literal task ("all tests pass"). Others pass it the why, too. The second one survives ambiguity. That's how /goal covers Part 2.
## Part 3. Desired Outcomes
What works for me is treating desired outcomes as observable states that show the objective is achieved. Not activities.
Rules:
- Observable states, not agent activities.
- From the user's perspective, not the agent's
- Measurable or verifiable without relying on agent self-report
- Leading, not lagging. Observable during or shortly after, not months later
For a support agent:
- Customer confirms their issue is resolved
- No follow-up ticket on same topic within 24 hours
- Customer rates interaction as helpful
Two to four outcomes is usually right. More than that, you're either micromanaging or unclear on what matters.
/goal enforces this discipline at the platform level. If your outcomes aren't measurable, the evaluator can't decide. The platform forces the spec.
## Part 4. Health Metrics (not in /goal)
Health metrics define what must not degrade while optimizing for outcomes. They pair with Part 3: outcomes are what you're achieving; health metrics are what you're protecting while you do.
Goodhart's Law: when a measure becomes a target, it stops being a good measure. Without health metrics:
- "Resolve issues faster" → agent rushes, quality drops
- "Increase throughput" → agent takes shortcuts
- "Reduce escalations" → agent handles things it shouldn't
Health metrics primarily inform the prompt layer. They guide how conservative the agent should be when making trade-offs:
```
- CSAT must stay above 4.2. If trending down, be more conservative.
- Repeat contact rate must not increase. Prioritize resolution quality.
- Escalation quality score must stay stable. Don't under-escalate to hit targets.
```
This is different from hard guardrails, which block actions entirely. Health metrics steer; guardrails enforce.
/goal doesn't model this layer. Your spec does.
## Part 5. Org Context (not in /goal)
Org context describes the world the agent operates in. It explains where the agent sits, not what it may do.
It includes:
- System context. Other agents, humans, tools, dependencies.
- Organizational context. Business model, users, brand.
For a support agent:
```
System: Works alongside human Tier-2 agents and self-serve KB.
Escalations go to human queue with full context.
Outputs feed ticket system and customer health scoring.
Organization: B2B software for enterprise.
Users are non-technical admins under time pressure.
Brand is built on reliability.
```
Not everything goes in the prompt. Core context (always needed) goes in the system prompt. Reference context goes in retrieval. Dynamic context (per-request) goes in the orchestration layer. System context can be automatically injected by the orchestration.
/goal doesn't address any of this.
## Part 6. Constraints: steering prompts vs. hard guardrails (not in /goal)
Constraints define what the agent is not allowed to do. They come in two forms. Most people miss the distinction.
Steering prompts (prompt-level):
- Behavioral guidance
- Risk preferences
- Tone and caution
They influence reasoning but do not enforce compliance. The model can ignore them under pressure. Steering doesn't constrain. It suggests.
Hard guardrails (orchestration-level):
- Tool restrictions
- Output validation
- Action gating
- Approval gates (human-in-the-loop)
If a constraint matters, it must be enforced in architecture, not language. Examples:
- Cannot send external emails
- Cannot modify account settings
- Cannot access other customers' data
- Cannot promise refunds or legal outcomes
The reasoning layer proposes. The orchestration layer enforces. If a constraint lives only in the prompt, it's a suggestion. If violating it is unacceptable, it has to live in code.
/goal enforces nothing here. Both Codex and Claude Code run inside whatever sandbox you've already configured. File permissions, network rules, MCP tool allowlists. The constraints are still your wiring.
## Part 7. Autonomy Boundaries (not in /goal)
All agent behavior reduces to four decision types. Each carries different risk.
1. Full Autonomy. Reversible actions, limited impact, well-understood failure modes.
2. Guarded Autonomy. User-visible changes, medium risk. Requires confidence thresholds, logging, rollback capability.
3. Proposal-First. Strategic or sensitive decisions. Agent proposes, approval required, agent executes.
4. No Autonomy (Human-Required). Legal commitments, irreversible changes, financial actions, brand promises. Agent analyzes and recommends. Human executes.
Autonomy defines permission, not stopping conditions.
The right autonomy depends on who bears the risk. When you build agents for yourself, you absorb the consequences. When you build agents into a product:
- Users may not know an agent acted
- Users can't assess AI-generated outputs
- Users will blame the company when it breaks
Rule I came up with: the less the user understands about what the agent is doing, the tighter your constraints need to be.
When designing agents, I also ask myself those five questions:
## Part 8. Stop Rules (not in /goal)
Stop rules define when execution must halt, escalate, or terminate. They do not guide trade-offs or decision quality.
```
Halt when:
- Conflicting constraints detected
- Confidence drops below minimum twice consecutively
Escalate when:
- Outside defined scope
- Legal or compliance topic detected
- User frustration persists
Complete when:
- Desired outcomes achieved
- User confirms resolution
```
/goal's auto-continue covers the complete branch. But "complete when outcomes achieved" is just your outcomes re-framed as a stop condition. The work was already in Part 3.
Halt and escalate are the load-bearing branches, and /goal ships neither. When confidence drops, when constraints conflict, when the topic shifts to legal or compliance, the agent has to know to stop instead of pushing through. That logic lives in your hooks, confidence thresholds, and escalation rules. Not in the slash command.
## Where /goal fits
Two of eight. The rest is on you.
## What to Do Tomorrow Morning
Open whatever file your agent reads on startup. When given a /goal, how can it discover:
1. Strategy. A few lines from your product strategy canvas. Vision, market segments, value propositions, trade-offs.
2. Health metrics. What must not degrade while the agent pursues the goal? Name two or three. Keep them qualitative if you can't measure live.
3. Org context. Two blocks: system (what's around the agent) and organization (who the agent serves).
4. Constraints. Separate the steering prompts (tone, caution, when to ask) from the hard guardrails (what's enforced in tools, hooks, sandbox).
5. Autonomy boundaries. Which decisions can the agent make alone? Which need approval? Which need a human?
6. Stop rules. Halt conditions (when to stop early), escalate conditions (when to hand off), complete conditions (your outcomes, already in /goal).
If you can hand your intent spec to another human that knows little about your product and they would make the same decisions under pressure, your agent has a chance. If not, it's missing the knowledge that never made it into the docs.
The models are capable enough. What separates agents that work in production from those that fail quietly is not intelligence, but clear intent.
## 相关链接
- [Paweł Huryn](https://x.com/PawelHuryn)
- [@PawelHuryn](https://x.com/PawelHuryn)
- [3.3K](https://x.com/PawelHuryn/status/2056109927727292629/analytics)
- [since 2024](https://x.com/PawelHuryn/status/1845165515724992693?s=20)
- [January 2026](https://www.productcompass.pm/p/intent-engineering-framework-for-ai-agents)
- [product strategy canvas](https://www.productcompass.pm/p/product-strategy-canvas)
- [Teaching Claude Why](https://www.anthropic.com/research/teaching-claude-why)
- [product strategy canvas](https://www.productcompass.pm/p/product-strategy-canvas)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:29 AM · May 18, 2026](https://x.com/PawelHuryn/status/2056109927727292629)
- [3,380 Views](https://x.com/PawelHuryn/status/2056109927727292629/analytics)
---
*导出时间: 2026/5/18 14:21:41*
---
## 中文翻译
# OpenAI 和 Anthropic 发布了 /goal，但你的智能体还需要另外六个部分
**作者**: Paweł Huryn
**日期**: 2026-05-17T20:29:42.000Z
**来源**: [https://x.com/PawelHuryn/status/2056109927727292629](https://x.com/PawelHuryn/status/2056109927727292629)
---
像优秀的组织管理赋能团队一样管理智能体。从 OKRs（2016）到赋能团队（2020），再到意图工程（2024）。/goal 只是八个部分中的两个。
4 月 30 日，OpenAI 在 Codex 中推出了 /goal。5 月 12 日，Anthropic 在 Claude Code 中推出了 /goal。两者都允许你设定一个可衡量的完成条件。智能体会自主运行，直到满足该条件。
自 2024 年以来，我一直在撰写关于像人类一样领导智能体的文章。我在 2026 年 1 月将这个八部分框架形式化：战略、风险、硬性护栏、自主边界以及另外四项。/goal 只是这八个部分中的两项。
## /goal 的作用及使用方法
两个实验室发布了相同的原语。你设定一个可衡量的完成条件。智能体会自主运行，直到满足条件或无法继续。
Codex CLI v0.128.0 于 4 月 30 日添加了 /goal，以及 /goal status、/goal pause、/goal resume 和 /goal clear。Claude Code v2.1.139 于 5 月 12 日添加了 /goal <condition>。两者都会自主运行，直到评估器模型判断条件已满足。
两者都无法为了澄清问题而妥善暂停。我直接测试了 Claude Code v2.1.139：设定了一个需要三个用户回答的目标，然后问了三个问题。Haiku 评估器在每次智能体轮次后都会触发，而不等待输入，返回类似“用户尚未回答这三个问题中的任何一个”的推理。一个目标触发了七次。没有暂停。
Codex 有一个旨在暂停以进行澄清的提问工具，但在实践中，它要么会自我循环，在一次运行中生成约 150 个重复问题，要么会挂起等待答案（openai/codex #21786, #23164）。只能向前的自主运行是默认模式。
用法：
```
/goal all tests pass and lint is clean
/goal ship the auth flow without breaking existing sessions
```
第一个锁定了字面任务。第二个锚定了意图。两者都有效。第二个能经得起歧义的考验。
这是一个真正的进步。但这也就是 /goal 止步的地方。
## 像管理人类一样管理智能体
你不会用“处理客户支持”这句话来入职一位高级产品经理（PM）。你会首先让他们立足于战略：愿景、市场、价值主张、权衡取舍。然后你才会给他们目标、证明成功的成果、他们所处的组织背景、绝不能下降的指标、约束条件、他们可以独自做出的决策以及何时升级处理。
智能体也需要同样的东西。同样的结构，同样的部分。
这个框架并不新鲜。顶层是产品战略。第 2 部分和第 3 部分是 Christina Wodtke 定义的 OKR 以及 Marty Cagan 定义的团队目标：
- 有意义的问题 + 为什么
- 期望的、可衡量的成果
第 4 到第 8 部分是赋能团队在该战略内部已有的运作方式。我做的创新是将所有这些应用于智能体。
智能体失败不是因为模型弱。它们失败是因为意图不完整。目标模糊。成果是隐含的。权衡取舍未声明。约束被视为建议。在未理解风险的情况下就授予了自主权。
/goal 解决了其中的一个切片。智能体现在有了目的地。它仍然必须决定如何到达那里。哪些行动是可逆的。哪些需要批准。在此过程中绝不能降低什么。何时停止而不是强行推进。
如果没有明确这些，智能体会自行编造。有时是对的。通常不是。
## 意图的八个部分
这八个部分是：
1. 战略。愿景、市场、价值主张、权衡取舍、增长。
2. 目标。问题及其重要性。
3. 期望成果。证明成功的可衡量状态。
4. 健康指标。在追求成果时绝不能降低的指标。
5. 组织背景。智能体所处的位置。系统和组织。
6. 约束。导向提示和硬性护栏。
7. 自主边界。哪些决定由智能体独自做出，哪些需要升级。
8. 停止规则。何时停止、升级或完成。
如果你写得好，/goal 涵盖了第 2 部分和第 3 部分。其他六个部分仍取决于你。
## 第 1 部分. 战略（不在 /goal 中）
战略是大多数智能体规范跳过的关键层：愿景、市场、价值主张、权衡取舍、增长。
它来自你的业务，而不是你的智能体。但智能体需要它。战略塑造了智能体应该做出的权衡取舍。这些都不在你的 CLAUDE.md / AGENTS.md 中。
做法：从你的产品战略画布中提取三行内容放入智能体的上下文中。渐进式披露。
## 第 2 部分. 目标
目标明确了问题及其重要性。当指令用尽时，它引导判断。
一个好的目标是以问题为导向的，说明其重要性，并指导在歧义下的权衡取舍。
弱：“处理客户支持工单。” 更好：“帮助客户快速解决问题，不要制造比开始时更多的挫败感。”
当你解释了原因，智能体就能对边缘情况进行推理。
> Anthropic 的《教 Claude 为什么》研究（2026 年 5 月 8 日）在训练方面验证了这一点：学习了对齐行动背后原因的模型，比仅通过行为演示训练的模型能更好地处理新颖情况。
/goal 接受这类目标。有些团队只给它字面任务（“所有测试通过”）。另一些团队也会给它“为什么”。第二种能经得起歧义的考验。这就是 /goal 如何涵盖第 2 部分的。
## 第 3 部分. 期望成果
对我有用的是将期望成果视为表明目标已实现的可观察状态。而不是活动。
规则：
- 可观察的状态，而不是智能体的活动。
- 从用户的角度，而不是智能体的角度
- 可衡量或可验证，且不依赖智能体的自我报告
- 领先的，而不是滞后的。在期间或 shortly after 可观察，而不是几个月后
对于支持智能体：
- 客户确认问题已解决
- 24 小时内同一主题无后续工单
- 客户评价互动为有帮助
两到四个成果通常是合适的。如果更多，你可能是在微观管理，或者不清楚什么才是重要的。
/goal 在平台层面强制执行这种纪律。如果你的成果不可衡量，评估器就无法决定。平台强制规范。
## 第 4 部分. 健康指标（不在 /goal 中）
健康指标定义了在优化成果时绝不能降低的内容。它们与第 3 部分配对：成果是你正在实现的；健康指标是你在实现过程中需要保护的。
古德哈特定律：当一个指标成为目标时，它就不再是一个好的指标。如果没有健康指标：
- “更快解决问题” → 智能体仓促行事，质量下降
- “增加吞吐量” → 智能体走捷径
- “减少升级” → 智能体处理它不该处理的事情
健康指标主要告知提示层。它们指导智能体在做出权衡时应多么保守：
```
- CSAT 必须保持在 4.2 以上。如果呈下降趋势，请更加保守。
- 重复联系率不得增加。优先考虑解决质量。
- 升级质量得分必须保持稳定。不要为了达到目标而升级不足。
```
这与完全阻止行动的硬性护栏不同。健康指标进行引导；护栏进行强制执行。
/goal 不对这一层进行建模。你的规范来处理。
## 第 5 部分. 组织背景（不在 /goal 中）
组织背景描述了智能体运行的世界。它解释了智能体的位置，而不是它可以做什么。
它包括：
- 系统上下文。其他智能体、人类、工具、依赖关系。
- 组织上下文。商业模式、用户、品牌。
对于支持智能体：
```
系统：与人工二级代理和自助服务知识库（KB）协同工作。
升级会带着完整的上下文进入人工队列。
输出反馈给工单系统和客户健康评分。
组织：面向企业的 B2B 软件。
用户是面临时间压力的非技术管理员。
品牌建立在可靠性的基础上。
```
并非所有内容都进入提示。核心上下文（总是需要）进入系统提示。参考上下文进入检索。动态上下文（每次请求）进入编排层。系统上下文可以由编排层自动注入。
/goal 不涉及这些。
## 第 6 部分. 约束：导向提示 vs. 硬性护栏（不在 /goal 中）
约束定义了智能体不允许做什么。它们有两种形式。大多数人忽略了这种区别。
导向提示（提示级）：
- 行为指导
- 风险偏好
- 语气和谨慎
它们影响推理但不强制合规。模型在压力下可以忽略它们。导向不是约束。它是建议。
硬性护栏（编排级）：
- 工具限制
- 输出验证
- 行动门控
- 批准门（人在回路）
如果一个约束很重要，它必须在架构中强制执行，而不是在语言中。例如：
- 不能发送外部电子邮件
- 不能修改账户设置
- 不能访问其他客户的数据
- 不能承诺退款或法律结果
推理层提出建议。编排层强制执行。如果约束仅存在于提示中，它就是一个建议。如果违反它是不可接受的，它就必须存在于代码中。
/goal 在这里不强制执行任何内容。Codex 和 Claude Code 都在你已配置的任何沙盒内运行。文件权限、网络规则、MCP 工具允许列表。约束仍然取决于你的布线。
## 第 7 部分. 自主边界（不在 /goal 中）
所有智能体行为都归结为四种决策类型。每种都有不同的风险。
1. 完全自主。可逆行动、影响有限、失败模式明确。
2. 受控自主。用户可见的更改、中等风险。需要置信度阈值、日志记录、回滚能力。
3. 提案优先。战略或敏感决策。智能体提出，需要批准，智能体执行。
4. 无自主（必须有人类）。法律承诺、不可逆更改、财务行动、品牌承诺。智能体分析和建议。人类执行。
自主定义的是权限，而不是停止条件。
正确的自主取决于谁承担风险。当你为自己构建智能体时，你自己承担后果。当你将智能体构建到产品中时：
- 用户可能不知道智能体采取了行动
- 用户无法评估 AI 生成的输出
- 出问题时用户会责怪公司
我想出的一条规则是：用户对智能体正在做的事情了解得越少，你的约束就需要越严格。
在设计智能体时，我还会问自己这五个问题：
## 第 8 部分. 停止规则（不在 /goal 中）
停止规则定义了何时必须停止、升级或终止执行。它们不指导权衡或决策质量。
```
当以下情况时停止：
- 检测到冲突的约束
- 置信度连续两次低于最低值
当以下情况时升级：
- 超出定义的范围
- 检测到法律或合规主题
- 用户持续不满
当以下情况时完成：
- 达到期望成果
- 用户确认解决
```
/goal 的自动继续涵盖了完成分支。但“当达到成果时完成”只是将你的成果重新表述为停止条件。这项工作已经在第 3 部分完成了。
停止和升级是承重分支，而 /goal 两者都没有提供。当置信度下降、约束冲突、主题转移到法律或合规时，智能体必须知道要停止而不是强行推进。该逻辑存在于你的钩子、置信度阈值和升级规则中。而不是在斜杠命令中。
## /goal 的位置
八个部分中的两个。剩下的取决于你。
## 明天早上做什么
打开智能体启动时读取的任何文件。当给定一个 /goal 时，它如何发现：
1. 战略。从产品战略画布中提取几行。愿景、细分市场、价值主张、权衡取舍。
2. 健康指标。在智能体追求目标时，绝不能降低什么？列出两三个。如果你无法实时测量，保持定性。
3. 组织背景。两个块：系统（智能体周围有什么）和组织（智能体服务谁）。
4. 约束。将导向提示（语气、谨慎、何时询问）与硬性护栏（在工具、钩子、沙盒中强制执行的内容）分开。
5. 自主边界。智能体可以独自做出哪些决定？哪些需要批准？哪些需要人类？
6. 停止规则。停止条件（何时提前停止）、升级条件（何时移交）、完成条件（你的成果，已在 /goal 中）。
如果你可以将意图规范交给另一个对你的产品知之甚少的人类，并且他们在压力下会做出相同的决定，那么你的智能体就有机会。如果不能，那就缺少了从未进入文档的知识。
模型已经足够强大。将生产环境中有效的智能体与那些默默失败的智能体区分开来的不是智能程度，而是清晰的意图。
## 相关链接
- [Paweł Huryn](https://x.com/PawelHuryn)
- [@PawelHuryn](https://x.com/PawelHuryn)
- [3.3K](https://x.com/PawelHuryn/status/2056109927727292629/analytics)
- [since 2024](https://x.com/PawelHuryn/status/1845165515724992693?s=20)
- [January 2026](https://www.productcompass.pm/p/intent-engineering-framework-for-ai-agents)
- [product strategy canvas](https://www.productcompass.pm/p/product-strategy-canvas)
- [Teaching Claude Why](https://www.anthropic.com/research/teaching-claude-why)
- [product strategy canvas](https://www.productcompass.pm/p/product-strategy-canvas)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:29 AM · May 18, 2026](https://x.com/PawelHuryn/status/2056109927727292629)
- [3,380 Views](https://x.com/PawelHuryn/status/2056109927727292629/analytics)
---
*导出时间: 2026/5/18 14:21:41*