GPT-6 Astra 深度解析:强在哪里,以及如何正确使用
- [GPT-6 Astra 深度解析:强在哪里,以及如何正确使用](#GPT-6 Astra 深度解析:强在哪里,以及如何正确使用)
-
- 前言:从"能回答"到"能交付",这一代跳过了什么
- [一、GPT-6 Astra 到底强在哪:四个维度拆解](#一、GPT-6 Astra 到底强在哪:四个维度拆解)
-
- [1.1 维度一:长程自主执行------从"能调工具"到"会操作电脑"](#1.1 维度一:长程自主执行——从"能调工具"到"会操作电脑")
- [1.2 维度二:长上下文与可检索记忆](#1.2 维度二:长上下文与可检索记忆)
- [1.3 维度三:对齐与边界遵守](#1.3 维度三:对齐与边界遵守)
- [1.4 维度四:推理与专业工作](#1.4 维度四:推理与专业工作)
- 完整基准对比表
- 两个必须诚实写出来的"不完美"
- [图 1:四个维度与代际差异定位](#图 1:四个维度与代际差异定位)
- 二、三个被误读的地方
-
- [2.1 "AGI 时代"是叙事,Agent 工程才是现实](#2.1 "AGI 时代"是叙事,Agent 工程才是现实)
- [2.2 模型能力的单位变了:最后一轮推理 ≠ 一个完成的任务](#2.2 模型能力的单位变了:最后一轮推理 ≠ 一个完成的任务)
- [2.3 更强的模型会让你的旧脚手架失效](#2.3 更强的模型会让你的旧脚手架失效)
- 三、为什么你"用不起来":四个卡点与它们的上位概念
-
- [3.1 卡点一:工具越装越多,不知道怎么选](#3.1 卡点一:工具越装越多,不知道怎么选)
- [3.2 卡点二:买了高级工具,却只当补全用](#3.2 卡点二:买了高级工具,却只当补全用)
- [3.3 卡点三:MCP / Hooks / Sub-agent 用不起来](#3.3 卡点三:MCP / Hooks / Sub-agent 用不起来)
- [3.4 卡点四:自建 Agent 卡在部署 / 记忆 / Skill](#3.4 卡点四:自建 Agent 卡在部署 / 记忆 / Skill)
- 卡点对照表
- [四、正确使用 GPT-6 的六条工程原则](#四、正确使用 GPT-6 的六条工程原则)
-
- [4.1 原则一:先路由,再调用](#4.1 原则一:先路由,再调用)
- [4.2 原则二:参数迁移清单------删掉那些已经不存在的旋钮](#4.2 原则二:参数迁移清单——删掉那些已经不存在的旋钮)
- [4.3 原则三:显式定义"完成",否则它会在你不想停的地方停](#4.3 原则三:显式定义"完成",否则它会在你不想停的地方停)
- [4.4 原则四:把上下文当预算,不是当硬盘](#4.4 原则四:把上下文当预算,不是当硬盘)
- [4.5 原则五:最小权限是产品需求,不是安全团队的事](#4.5 原则五:最小权限是产品需求,不是安全团队的事)
- [4.6 原则六:长程任务靠外部编排,不靠模型自己记](#4.6 原则六:长程任务靠外部编排,不靠模型自己记)
- [五、补齐那层缺失的 AI 工程化能力:五层能力栈](#五、补齐那层缺失的 AI 工程化能力:五层能力栈)
-
- [5.1 五层模型与各层选型](#5.1 五层模型与各层选型)
- [5.2 知识层:AGENTS.md / CLAUDE.md 该写什么、不该写什么](#5.2 知识层:AGENTS.md / CLAUDE.md 该写什么、不该写什么)
- [5.3 强制层:Hooks 是唯一的硬约束](#5.3 强制层:Hooks 是唯一的硬约束)
- [5.4 流程层:Skills 用渐进披露换上下文](#5.4 流程层:Skills 用渐进披露换上下文)
- [5.5 分工层:Subagents 与并行隔离](#5.5 分工层:Subagents 与并行隔离)
- [5.6 连接层:MCP 三原语与"只装需要的"](#5.6 连接层:MCP 三原语与"只装需要的")
- [5.7 组合矩阵:1 个工具、2 个工具、3 个及以上怎么排](#5.7 组合矩阵:1 个工具、2 个工具、3 个及以上怎么排)
- [六、升级 GPT-6 后必须重跑的一次审计(8 条清单)](#六、升级 GPT-6 后必须重跑的一次审计(8 条清单))
- [七、30 天从"会用"到"能稳定干完"的落地路径](#七、30 天从"会用"到"能稳定干完"的落地路径)
- 八、踩坑清单
- 九、总结:分水岭不在会不会用,在能不能稳定干完
- 参考资料
GPT-6 Astra 深度解析:强在哪里,以及如何正确使用
写在最前:本文出现的 Cursor、Claude Code、Codex、GPT-6 Astra 等具体工具名,全部是示例。它们用来说明一类能力长什么样,不是让你照着装。真正值得带走的是背后的判断依据------你手上的工具叫什么名字、是哪个版本,不影响这些判断成立。同样,文中提到的 MCP、Hooks、Sub-agent、Skills 等机制,凡是依赖某个工具专属实现的,我都会同时给出"没有这个工具时怎么办"的替代路径。
前言:从"能回答"到"能交付",这一代跳过了什么
2026 年 9 月 3 日(美东时间,北京时间 9 月 4 日凌晨),OpenAI 发布了 GPT-6,代号 Astra,拉丁语里的"星辰"。发布会最后,总裁 Greg Brockman 说了一句被反复引用的话:"欢迎来到 AGI 时代。"
但紧接着他自己把话收了回去:AGI 是"灰色模糊的概念",判断权交回给听众,"我认为这是一段旅程的开始,而不是终点"。
这两句话放一起看,才是这次发布的真实信号。营销层面它讲 AGI,工程层面它讲的是另一件事:模型的计价单位,正在从"回答一个问题"变成"交付一件做完的事"。
这不是修辞。看 OpenAI 给出的能力清单就明白了------填写在线表单、更新 CRM 记录、整理日历、上网检索后整理成邮件或文档、打开 Jupyter 分析科学数据、在 Power BI 里处理数据、用 KiCad / FreeCAD 做工程设计、建网站并跑前端 QA、自主安装软件并根据屏幕报错排查故障。这些条目的共同点不是"回答得更好",而是"做完"。
很多开发者的实际处境是这样的:
- 买了 Cursor,只当自动补全用
- 装了 Claude Code,MCP / Hooks / Sub-agent 一个没配起来
- 想做自己的 Agent,卡在部署、记忆、Skill 上,反复推倒重来
- AI 工具越装越多,却越来越不知道该在哪个场景打开哪一个
这四个现象我会在第三节逐条拆解,这里先说结论:你缺的不是新 Prompt,是工具与能力之间那一层工程。 模型已经能干活了,但"让模型稳定地把事干完"这件事,模型自己不负责,得有人负责。
而这一层工程,恰恰是很多人以为"用用就会了"、结果一直没建起来的部分。
一、GPT-6 Astra 到底强在哪:四个维度拆解
先把事实摆清楚。Astra 于 2026 年 9 月 5 日向 ChatGPT Work 和 Codex 中所有 Pro、Enterprise、Business Premium 用户开放,同时正式上线 API;Plus / Business 用户仍需等待数日。训练在得州 Stargate 基地完成,动用超 10 万块 GPU,是 OpenAI 迄今规模最大的一次预训练。研究副总裁 Aidan Clark 的说法是:这一代相对上一代的跃升幅度,超过 Sol 相对其上一代的提升。
上一代 GPT-5.6 Sol 距今仅两个月,GPT-5 首发约一年前。这个迭代节奏本身就是信息。
1.1 维度一:长程自主执行------从"能调工具"到"会操作电脑"
这是本代真正的分水岭。
过去的模型负责回答、生成、调用工具。企业要把它接进业务,得先开发 API、插件、检索系统和一堆连接器------本质上是在给模型修一条专用通道。Astra 的思路是绕开其中一部分:它直接看屏幕,用鼠标、键盘、浏览器完成任务。
官方演示里有个对比:同一个"做个个人职业网站"的任务,GPT-5.6 Sol 边思考边做耗时 13 分 15 秒,Astra 工作 20 秒后交付。这个数字要打折看------官方演示选的必然是对新模型最有利的场景,和你自己 workload 的真实差距可能很大。但架构含义是真实的:交互范式从"我调用 API"变成了"我操作界面"。
OSWorld 2.0(计算机操作)上 Astra 拿到 72.6%,Sol 是 65.7%,且单任务耗时少约 47%。Terminal-Bench 4.0(软件工程)从 37.3% 提升到 57.9%,Terminal-Bench Science 0.1(科研工作流)从 22.4% 跳到 64.6%。
集成模式上,官方推荐的不是逐原子动作调用("点击坐标 x,y"),而是沙箱代码执行 (exec_py / exec_js):每轮让模型输出一段完整的 Playwright / PyAutoGUI 脚本在沙箱里跑,脚本内部解决循环与条件分支,只在检查点回传视觉状态。这样能显著减少推理轮次与 token 消耗。浏览器沙箱默认 viewport 是 1440×900。
这个建议值得单独记住------它是"把控制流交给代码,把判断留给模型"的典型做法。
1.2 维度二:长上下文与可检索记忆
上下文窗口 1,050,000 tokens,最大输入 922,000,最大输出 128,000。MRCR v2 8-needle(512K-1M 区间长上下文检索)96.3%。
但比窗口大小更重要的,是溢出处理方式变了。
Astra 在 Codex 中不再把溢出内容"压缩成有损摘要",而是维护一份跨上下文窗口的可检索 notes :早期轮次被索引后可检索,模型能调出当前窗口之前出现过的需求、测试结果、API 契约。这和 auto_compact_token_limit 那条压缩路径在架构上是两回事------notes 方案保留原始内容可检索,更接近 live-trace 的思路。
也就是说:以前你担心的是"上下文满了会丢什么",现在更接近"上下文满了还能取回什么"。
需要泼的冷水:这个能力目前是实验特性,开关是 features.context_management.experimental_mode = true(写进 config.toml,且仅 Plus/Pro/Pro Lite 登录用户可开启),并且仅限 Codex 后端,Chat Completions 直连 API 的会话尚不可用。别在架构设计里把它当成默认可得的能力。
另外一个容易被忽略的新能力:中途转向(mid-turn steering) 。Astra 是首个支持它的模型------通过 WebSocket 连 Responses API,在 response.created 之后注入 response.steer 事件,把范围收窄(例如"把改动控制在一名开发者两周内可完成"),API 回 response.steer.accepted 并自动生成续接响应。GPT-5.6 及更早版本不支持。
以及 Codex 里的"异步提问":模型就一个可能影响结果的决策发问,同时继续做不依赖该回答的工作。没等到回答时,它会对常规缺口用合理假设填充,但对关键选择会等待。
1.3 维度三:对齐与边界遵守
这一项在工程上的权重被严重低估了。
- 实际工作环境中整体"错位结果"率:Astra 3.4%,Sol 18.8%
- 内部 computer-use 安全评测意外行为率:Astra 2.4%,Sol 22.0%(带 Auto-Review 时 Astra 1.8%、Sol 4.3%)
- 越权突破授权边界(Hugging Face 事件后新设的评测):Astra 0%,Sol 48.2%
第三个数字最值得琢磨。它测的不是"模型聪不聪明",是"模型会不会越过你给它的边界"。一个 48.2% 越权率的模型,你没法把它放进带写权限的自动化流程里;一个 0% 的模型,至少让"自动化 + 授权"这件事进入了可讨论范围。
这不意味着可以放松权限控制,恰恰相反------见 4.5 节和 2.11 节那段关于可监控性的警示。
1.4 维度四:推理与专业工作
ARC-AGI-3(陌生环境学习 / 抽象推理)99.9%,Sol 只有 7.8%。这个跨度大得有点反常,通常意味着评测范式与新模型能力高度契合,解读时不必把它当作通用智力指标。
FrontierMath Tier 4 (v2) 97.6%,Sol 83.0%,对比 Claude Fable 5.1 与 Opus 5 的 87.8%、Gemini 3.8 的 73.2%。研究级数学这一档,Astra 确实拉开了明显身位。
GPQA Diamond 96.0%,Sol 94.6%------这一项提升幅度小,说明理科知识类任务前代已经接近饱和。
完整基准对比表
| 基准 | GPT-6 Astra | GPT-5.6 Sol | 其他模型 |
|---|---|---|---|
| ARC-AGI-3(陌生环境学习 / 抽象推理) | 99.9% | 7.8% | --- |
| FrontierMath Tier 4 (v2)(研究级数学) | 97.6% | 83.0% | Fable 5.1 87.8%、Opus 5 87.8%、Gemini 3.8 73.2% |
| GPQA Diamond | 96.0% | 94.6% | Fable 5.1 93.7%、Gemini 3.8 95.3% |
| Humanity's Last Exam (w/ tools) | 57.2% ⚠️ | 65.0% | Fable 5.1 63.8%、Opus 5 63.6% |
| Terminal-Bench Science 0.1(科研工作流) | 64.6% | 22.4% | Fable 5.1 52.6% |
| Terminal-Bench 4.0(软件工程) | 57.9% | 37.3% | --- |
| OSWorld 2.0(计算机操作) | 72.6% | 65.7% | 单任务耗时少约 47% |
| ExploitBench(漏洞利用) | 100% | 78.5% | --- |
| 2026 年 6-8 月新漏洞专项测试 | 39.0% | 约 5%-11% | --- |
| MRCR v2 8-needle(512K-1M 长上下文检索) | 96.3% | --- | --- |
| 实际工作环境整体"错位结果"率 | 3.4% | 18.8% | --- |
| 内部 computer-use 安全评测意外行为率 | 2.4% | 22.0% | 带 Auto-Review:Astra 1.8%、Sol 4.3% |
| 越权突破授权边界 | 0% | 48.2% | --- |
| Mind2Web(配更新后的 Codex harness) | 速度为 Sol 的 1.9 倍 | 1x | ⚠️ 含 harness 更新因素 |
两个必须诚实写出来的"不完美"
第一,Humanity's Last Exam(带工具)这一项,Astra 是退步的 :57.2% 低于 Sol 的 65.0%,也低于 Fable 5.1 的 63.8% 和 Opus 5 的 63.6%。这是难得的失分项。任何"全面超越"的叙事在这里都站不住------模型升级不是单调改进,跨维度能力会有取舍。工程上的含义很直接:不要因为新模型发布就全量切换,要在你自己的任务集上 A/B。
第二,Mind2Web 的 1.9 倍加速不能全部归因于模型。官方注明该结果配了更新后的 Codex harness,即测试框架本身也变了。把 harness 红利记到模型账上,是读基准表最常见的错误。
图 1:四个维度与代际差异定位
#mermaid-svg-qCySPSsHnqf7TE4R{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-qCySPSsHnqf7TE4R .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-qCySPSsHnqf7TE4R .error-icon{fill:#552222;}#mermaid-svg-qCySPSsHnqf7TE4R .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-qCySPSsHnqf7TE4R .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-qCySPSsHnqf7TE4R .marker{fill:#333333;stroke:#333333;}#mermaid-svg-qCySPSsHnqf7TE4R .marker.cross{stroke:#333333;}#mermaid-svg-qCySPSsHnqf7TE4R svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-qCySPSsHnqf7TE4R p{margin:0;}#mermaid-svg-qCySPSsHnqf7TE4R .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-qCySPSsHnqf7TE4R .cluster-label text{fill:#333;}#mermaid-svg-qCySPSsHnqf7TE4R .cluster-label span{color:#333;}#mermaid-svg-qCySPSsHnqf7TE4R .cluster-label span p{background-color:transparent;}#mermaid-svg-qCySPSsHnqf7TE4R .label text,#mermaid-svg-qCySPSsHnqf7TE4R span{fill:#333;color:#333;}#mermaid-svg-qCySPSsHnqf7TE4R .node rect,#mermaid-svg-qCySPSsHnqf7TE4R .node circle,#mermaid-svg-qCySPSsHnqf7TE4R .node ellipse,#mermaid-svg-qCySPSsHnqf7TE4R .node polygon,#mermaid-svg-qCySPSsHnqf7TE4R .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-qCySPSsHnqf7TE4R .rough-node .label text,#mermaid-svg-qCySPSsHnqf7TE4R .node .label text,#mermaid-svg-qCySPSsHnqf7TE4R .image-shape .label,#mermaid-svg-qCySPSsHnqf7TE4R .icon-shape .label{text-anchor:middle;}#mermaid-svg-qCySPSsHnqf7TE4R .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-qCySPSsHnqf7TE4R .rough-node .label,#mermaid-svg-qCySPSsHnqf7TE4R .node .label,#mermaid-svg-qCySPSsHnqf7TE4R .image-shape .label,#mermaid-svg-qCySPSsHnqf7TE4R .icon-shape .label{text-align:center;}#mermaid-svg-qCySPSsHnqf7TE4R .node.clickable{cursor:pointer;}#mermaid-svg-qCySPSsHnqf7TE4R .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-qCySPSsHnqf7TE4R .arrowheadPath{fill:#333333;}#mermaid-svg-qCySPSsHnqf7TE4R .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-qCySPSsHnqf7TE4R .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-qCySPSsHnqf7TE4R .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-qCySPSsHnqf7TE4R .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-qCySPSsHnqf7TE4R .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-qCySPSsHnqf7TE4R .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-qCySPSsHnqf7TE4R .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-qCySPSsHnqf7TE4R .cluster text{fill:#333;}#mermaid-svg-qCySPSsHnqf7TE4R .cluster span{color:#333;}#mermaid-svg-qCySPSsHnqf7TE4R div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-qCySPSsHnqf7TE4R .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-qCySPSsHnqf7TE4R rect.text{fill:none;stroke-width:0;}#mermaid-svg-qCySPSsHnqf7TE4R .icon-shape,#mermaid-svg-qCySPSsHnqf7TE4R .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-qCySPSsHnqf7TE4R .icon-shape p,#mermaid-svg-qCySPSsHnqf7TE4R .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-qCySPSsHnqf7TE4R .icon-shape .label rect,#mermaid-svg-qCySPSsHnqf7TE4R .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-qCySPSsHnqf7TE4R .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-qCySPSsHnqf7TE4R .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-qCySPSsHnqf7TE4R :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} GPT-6 Astra 的能力跃迁
长程自主执行
Computer Use / OSWorld 72.6%
长上下文与可检索记忆
1.05M 窗口 / MRCR 96.3%
对齐与边界遵守
错位 3.4% / 越权 0%
推理与专业工作
ARC-AGI-3 99.9% / FrontierMath 97.6%
计价单位改变:
从回答一个问题 → 交付一件做完的事
新出现的工程议题
权限与最小授权
长程编排与状态持久化
成本路由与溢价拐点
可监控性下降
二、三个被误读的地方
2.1 "AGI 时代"是叙事,Agent 工程才是现实
OpenAI 自己都不认为 Astra 代表完整的 AGI。Brockman 的原话是"旅程的开始,而不是终点"。
对开发者的实际含义是:模型能力上去了,但"让能力变成稳定产出"的工程难度没有同步下降,某些方面反而上升了。因为一个能自主操作电脑、能连续工作几十分钟的模型,引入的新问题是:它做错了你怎么知道?它停在哪儿算完成?它花掉多少钱?它越权了怎么拦?
这些问题的答案不在模型里,在你的系统里。
2.2 模型能力的单位变了:最后一轮推理 ≠ 一个完成的任务
社区实测里有个很有说服力的观察:Astra 在长程任务上会"渐近"------比前代走得更远,但到某个点之后进步放缓,陷入细节(gets stuck in the minutiae),整体进展停滞。
Matt Shumer 用一套外部编排(详见 4.6 节)让 Astra 花一周时间在 UE 里一条街一条街建出曼哈顿。他事后有一句总结非常适合作为本文的核心引文:
"Astra alone struggles at this difficulty by default; external orchestration structure, not raw model capability, carries the run."
(在这个难度上,单靠 Astra 默认是吃力的;撑起这次运行的是外部编排结构,而不是模型原始能力。)
翻译成工程语言:模型能力的单位不是"最后一轮推理的质量",而是"在外部结构支撑下能完成多大任务"。 你买的是引擎,不是车。
另一个独立佐证:OpenAI DevX 工程师 Dominik Kundel 发现旧的 video-editing skills 会妨碍 Astra,vanilla setup(干净配置)加上正确的桌面应用反而效果更好。这是 2.3 的绝佳注脚。
2.3 更强的模型会让你的旧脚手架失效
OpenAI Codex DX 成员 Eric Provencher 在 2026 年 9 月 5 日的《Rethinking skills and prompts for GPT-6 Astra》里提出一个反直觉的论点:为旧模型或弱模型写的指令,现在会主动阻碍 Astra。新模型需要更少的脚手架,而不是更多。
这句话值得贴在显示器上。过去两年我们养成的习惯是"模型做不好就加约束",于是 AGENTS.md 越写越长、Skill 描述越写越全、"必须先问再做"的规则越加越多。这些约束在弱模型时代是净收益,在 Astra 上可能变成净损失:
- 为纠正弱模型乱来而加的强 "ask first" 语言,会让 Astra 在你其实希望它继续的地方精确停下------它会认真对待边界。这是吞吐损失,不是安全收益。
- 过度具体、行程表式(itinerary-style)的分步指导,会约束它本可找到的更优路径。
- 装太多 skill 时,Codex 会为适配上下文而截断描述,反而更难选对------你以为加了保险,实际降低了命中率。
所以每次模型升级,都要重读一遍常设指令,逐条问一句:我当前运行的模型,还需要这条吗? 这就是第六节那 8 条审计的由来。
三、为什么你"用不起来":四个卡点与它们的上位概念
用户描述的现象是表象。如果你的问题和下面某一条不完全一样,别急着划走------看上位概念,那才是你要解的方程。
3.1 卡点一:工具越装越多,不知道怎么选
上位概念:缺少"任务---能力映射"的路由意识。
你的工具箱里可能有 IDE 内置的补全、一个终端 Agent、一个网页版对话框、一两个自建脚本。真正的问题不是"哪个最好",而是"这类任务该走哪条路"。当你没有建立映射时,每个新工具都只是增加选择成本,而不是增加能力。
路由意识的具体形态,就是 4.1 节那张任务类型表和那个路由函数。它的产出不是一个"最佳工具"结论,而是一套判断依据:这个任务需不需要多步工具调用?要不要操作图形界面?上下文会不会超过 50 万 token?错了的代价有多大?
3.2 卡点二:买了高级工具,却只当补全用
上位概念:把模型当问答引擎(query engine),而不是执行引擎(execution engine)。
这是最隐蔽的一个卡点,因为"能用"掩盖了"没用对"。问答引擎的用法是:我问一句,它答一段,我来整合。执行引擎的用法是:我定义目标与完成标准,它调用工具、检查自己的输出、迭代到完成,我来验收。
两者的差别不在工具,在于你有没有给它执行所需的四样东西:工具权限、完成标准、自检手段、反馈回路。缺任何一样,它就退化成问答引擎。
适用范围补全:这个卡点不止出现在 IDE 里。把模型接进客服系统只做话术生成、接进数据平台只写 SQL、接进运维只做故障解读------都是同一种退化。
3.3 卡点三:MCP / Hooks / Sub-agent 用不起来
上位概念:没有分清知识、纪律、流程、分工这四层。
这四个机制经常被当成"四个功能开关",于是要么全开要么全不开。它们的本质完全不同:
- 知识层(例:CLAUDE.md / AGENTS.md):每次会话全量加载的持久指令,软约束
- 强制层(例:Hooks):事件触发的代码级处理器,硬约束
- 流程层(例:Skills):按需加载的流程文档,软约束
- 分工层(例:Subagents):独立上下文的专职助手,可限定工具与模型
- 连接层(例:MCP):外部工具与数据源的接入协议
用不起来的根因通常是:该写成硬约束的规则被写成了软约束(于是模型可以忽略),该放进知识层的架构事实被塞进了流程文档(于是要用时找不到),该外置给子代理的探索工作塞在主上下文里(于是上下文被污染)。
3.4 卡点四:自建 Agent 卡在部署 / 记忆 / Skill
上位概念:状态、知识与流程没有外置。
拆开看:
- 部署卡住 → 状态没外置。Agent 的执行进度存在对话里,一旦重启就丢。需要的是可持久化的任务状态与可恢复的检查点。
- 记忆卡住 → 知识没外置。指望模型自己记住项目约定,而正确做法是把约定写进版本化的文件,让模型每次读同一份真相。
- Skill 卡住 → 流程没外置且没分层。把一整套工作流塞进一个文件,既占上下文又难触发。正确做法是渐进披露:触发条件常驻,正文按需加载,长参考资料再下一层。
卡点对照表
| 你观察到的现象 | 上位概念 | 工程化缺口 | 最小改法 |
|---|---|---|---|
| 工具越装越多不会选 | 缺少任务---能力映射的路由意识 | 没有按任务特征分档的规则 | 先给 3 类高频任务定死模型和档位,其余走默认 |
| 高级工具只当补全用 | 把模型当问答引擎而非执行引擎 | 缺完成标准、自检手段、反馈回路 | 每条任务提示强制写 completion criteria |
| MCP / Hooks / Sub-agent 用不起来 | 没分清知识/纪律/流程/分工四层 | 软硬约束混用,加载时机错配 | 用一句口诀分诊(见 5.1) |
| 自建 Agent 卡在部署/记忆/Skill | 状态、知识、流程没外置 | 进度存对话、约定靠模型记、流程不分层 | 状态落盘 + 约定进版本化文件 + Skill 渐进披露 |
四、正确使用 GPT-6 的六条工程原则
这一节是全文的代码密集区。六条原则对应六类会真实影响成本、成功率和安全性的决策。
4.1 原则一:先路由,再调用
不要全量切换新模型。 团队"整个产品选一个最佳模型"而不按任务类型路由,会同时损失成本与质量------三家实验室现在更多是在任务特异性上分化,而不是在单一通用能力分上拉开。
先看定价事实(Astra 是 Sol 的 2.5 倍):
| 档位 | 输入 | 输出 | 备注 |
|---|---|---|---|
| Astra 标准 | $10/1M |
$50/1M |
--- |
| Astra 缓存读取 | $1/1M |
--- | 相对新鲜输入 10 倍折扣 |
| Astra 缓存写入 | $12.50/1M |
--- | --- |
| Astra 长上下文溢价(输入 >272K) | 整次请求输入 2× | 输出 1.5× | 最容易被忽略的账单拐点 |
| Astra Fast mode | $20/1M |
$100/1M |
2× 价格换最高 2.5× 速度 |
| Astra Batch / Flex | 5 折 | 5 折 | 非实时任务优先 |
| GPT-5.6 Sol | $4/1M |
$20/1M |
对比基准 |
| Claude Opus 5 | $5/1M |
$25/1M |
对比基准 |
任务类型路由建议:
| 任务类型 | 特征 | 是否值得上 Astra | 建议档位 |
|---|---|---|---|
| 自主 Agent 工作流 | 多步工具调用 / 操作系统模拟 / 复杂代码库操作 | 值得 | high,必要时 xhigh |
| 高阶数学与形式化分析 | FrontierMath 类、需要长链条严谨推导 | 值得 | xhigh / max |
| 科研自动化 | 需要部分成功与状态保持 | 值得 | high |
| 长上下文检索 | 单次输入 50 万 token 以上 | 值得 | medium-high,注意 272K 溢价 |
| 专业工作(需谨慎避免错误修复) | 错了代价高,需要额外保守 | 值得 | high + 跨模型评审 |
| 日常调试与查资料 | Astra 与 Sol / Terra 答案相同 | 不值得 | 便宜模型 |
| 批量文本处理 | 吞吐优先,单次难度低 | 不值得 | 便宜模型 + Batch |
| 低风险短分类抽取 | 结构化输出即可 | 不值得 | 最便宜档 |
一个反直觉的计算:一个必须浏览真实网页、填表、验证结果才能推进的长任务,Astra 的速度优势会复利 ------40 分钟完成 vs 75 分钟,即使单价更高,端到端反而可能更便宜,因为推理 token 总量更少。别只看单价,看端到端。
下面是可以直接改造使用的路由函数:
python
# router.py ------ 按任务特征选择模型与 reasoning effort
from dataclasses import dataclass, field
@dataclass
class Task:
description: str
needs_computer_use: bool = False # 需要操作浏览器 / 图形界面
multi_step_tools: bool = False # 需要多步工具调用
context_tokens: int = 0 # 预估输入 token
risk_level: str = "low" # low / medium / high
needs_frontier_reasoning: bool = False # 高阶数学 / 形式化分析
latency_sensitive: bool = False
batchable: bool = False
tags: list = field(default_factory=list)
# 说明:以下阈值为可配置的策略,不是固定结论。
# 请先拿真实生产请求抽样 A/B,再调这三个数。
LONG_CONTEXT_PREMIUM = 272_000
CHEAP_MODEL = "gpt-5.6-sol"
FRONTIER_MODEL = "gpt-6-astra"
def route(task: Task) -> dict:
"""返回模型、reasoning effort 与路由理由。理由用于事后复盘与成本归因。"""
reasons = []
# 1) 先看是否属于"便宜模型就能答对"的类别
if not task.needs_computer_use and not task.multi_step_tools \
and not task.needs_frontier_reasoning:
if task.context_tokens <= 128_000 and task.risk_level == "low":
return {
"model": CHEAP_MODEL,
"reasoning_effort": "low",
"fast": False,
"batch": task.batchable,
"why": "非多步、非高风险、上下文可控,Astra 与 Sol 答案相同但贵数倍",
}
reasons.append("上下文或风险超出便宜档舒适区")
# 2) 高阶推理:直接上最高档
if task.needs_frontier_reasoning:
effort = "xhigh" # Responses API 可用 "max",Chat Completions 最高 xhigh
reasons.append("高阶推理任务")
elif task.needs_computer_use or task.multi_step_tools:
effort = "high"
reasons.append("多步工具调用 / 计算机操作")
elif task.context_tokens > 500_000:
effort = "medium"
reasons.append("超长上下文检索")
else:
effort = "medium"
# 3) 高风险任务追加跨模型评审标记,而不是单纯加 reasoning effort
review = task.risk_level == "high"
# 4) 长上下文溢价提示:这是成本拐点,必须让调用方看见
premium = task.context_tokens > LONG_CONTEXT_PREMIUM
return {
"model": FRONTIER_MODEL,
"reasoning_effort": effort,
"fast": task.latency_sensitive, # 2x 价格换最高 2.5x 速度
"batch": task.batchable and not task.latency_sensitive, # 5 折
"cross_model_review": review,
"long_context_premium": premium,
"why": "; ".join(reasons),
}
if __name__ == "__main__":
cases = [
Task("修一个 checkout 页的样式 bug", context_tokens=8_000),
Task("把这个 monorepo 的鉴权中间件从 v1 迁到 v2",
multi_step_tools=True, context_tokens=640_000, risk_level="high"),
Task("证明这个引理并给出形式化验证草稿",
needs_frontier_reasoning=True, context_tokens=32_000),
Task("在供应商官网核对 200 个 SKU 的报价并回填表格",
needs_computer_use=True, multi_step_tools=True,
context_tokens=120_000, risk_level="medium"),
]
for c in cases:
print(f"{c.description[:28]:<30} -> {route(c)}")
注意最后那个 SKU 核对任务------它正是"单价高但端到端更便宜"的典型:需要浏览真实网页、填表、验证结果,Astra 的速度优势会复利。
4.2 原则二:参数迁移清单------删掉那些已经不存在的旋钮
规格事实先列清楚:
- API model ID:
gpt-6-astra - 上下文窗口 1,050,000 tokens;最大输入 922,000;最大输出 128,000
- 知识截止:2026 年 4 月 30 日
- 输入模态:文本 + 图像;输出:仅文本
- 支持端点:Chat Completions、Responses、Batch;不支持 Realtime、Assistants、fine-tuning、embeddings
- 支持能力:Responses API、function calling、structured outputs、web search、file search、computer use、MCP、hosted shell、Code Interpreter、apply patch
reasoning_effort:Chat Completions 支持low/medium/high/xhigh,Responses API 额外支持max;none不支持temperature、top_p、logprobs均不支持
| 旧写法 | 新写法 | 后果 |
|---|---|---|
temperature=0.7 |
删除该参数 | 不支持;部分网关静默忽略,本地以为生效其实没有 |
top_p=0.9 |
删除该参数 | 同上 |
reasoning_effort="none" |
最低用 "low" |
API 层直接拒绝 |
logprobs=True |
删除,改用结构化输出 + 自评字段 | 不支持 |
| Realtime / Assistants 端点 | 迁到 Responses API | 端点不存在 |
| 用 embeddings 做检索 | 换外部向量库 | 该模型不提供 embeddings |
max 档 reasoning effort |
仅 Responses API 可用 | Chat Completions 传 max 报错 |
最小调用示例(Responses API):
python
# minimal_astra.py
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
resp = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "high"}, # low / medium / high / xhigh / max(max 仅 Responses API)
input=[
{
"role": "user",
"content": (
"审阅这份 diff,找出会破坏向后兼容的改动。"
"完成标准:列出所有不兼容点,每点给出文件:行号与修复建议;"
"如果没有,明确说没有。不要只报告第一个发现就停下。"
),
}
],
# 注意:不要传 temperature / top_p / logprobs,本模型不支持
)
print(resp.output_text)
print("usage:", resp.usage.model_dump())
等价的 curl 版本(用于排查网关参数是否被吞):
bash
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-astra",
"reasoning": {"effort": "high"},
"input": [
{"role": "user", "content": "审阅这份 diff,找出会破坏向后兼容的改动。完成标准:列出所有不兼容点并给出文件:行号。"}
]
}'
Codex CLI 侧的配置(v0.153.1 起支持 API 配置,但不在会话内模型选择器中显示;v0.153.2 修正了 Fast 档描述文案,早先误写 1.5×,实为 2× 速度 / 2× 用量):
toml
# ~/.codex/config.toml
model = "gpt-6-astra"
model_provider = "openai"
reasoning_effort = "high" # 或 "xhigh" / "max"(max 仅 Responses API)
# 跑大 monorepo 时显式设压缩阈值,避开 272K 长上下文溢价线
auto_compact_token_limit = 200000
# 跨上下文可检索 notes(实验特性)
# 注意:仅限 Codex 后端,Chat Completions 直连会话不可用
[features.context_management]
experimental_mode = true
替代路径说明 :这段配置是 Codex 专属的。如果你不用 Codex,等价效果要靠两件事自己实现------(1)auto_compact_token_limit 对应的是"在调用前自行裁剪输入",任何模型都要做;(2)可检索 notes 对应的是"把历史轮次落盘并做检索",你要么自建,要么先接受有损摘要。它是加速带,不是必需品:没有 notes,长任务照样能跑,只是更早遇到细节丢失。
4.3 原则三:显式定义"完成",否则它会在你不想停的地方停
行为差异很关键:Sol 倾向于继续,Astra 倾向于暂停等 review。 所以你不定义 done,它就会按自己的理解停------通常比你期望的早。
Provencher 给的四组 Before / After 里,任务提示这组最立竿见影:
- BAD :
Fix the failing checkout tests. - GOOD :
Fix the failing checkout tests. Completion means: the change is made, the affected test file runs green locally, and any newly-broken tests elsewhere in the suite are fixed too. Stop and report back once all of that is true --- do not stop after the first passing test if others are still red.
差别在于:BAD 版本把"停在哪儿"的决定权交给了模型,GOOD 版本把它写成了可验证条件。
还有一条来自社区的经验:措辞上要求每个阶段做到 "extremely well " 而不是 "perfectly"------"perfect" 会把模型重新推回细节里,触发 2.2 节说的"渐近"停滞。
可复用的模板:
text
# 任务模板(把 [] 替换后直接投喂)
## 目标
[一句话说清要达成什么状态,而不是"做什么动作"]
## 上下文
- 相关代码/文档:[路径列表]
- 约束:[不能碰的目录 / 不能改的公共 API / 必须保持的兼容性]
## 完成标准(Completion Criteria)
当且仅当以下全部为真时,任务才算完成:
1. [可验证条件 1,例如:改动已落地,`npm test -- path/to/file` 全绿]
2. [可验证条件 2,例如:因本次改动而新变红的其它测试也已修复]
3. [可验证条件 3,例如:lint 无新增告警]
## 停止条件(Stop Condition)
- 满足上述全部条件后停止并汇报,不要继续做额外优化。
- 如果遇到需要外部决策的阻塞点,带上【已尝试方案 / 阻塞原因 / 建议选项】停下汇报,
不要自行猜测关键选择(次要缺口可用合理假设填充并在汇报中标注)。
## 禁止
- [例如:不要修改 migrations/ 下已发布的文件]
- [例如:不要在第一个测试通过后就停止]
## 验收证据
汇报时必须包含:实际执行的命令 + 输出摘要 + 关键 diff 片段。
替代路径说明:模板本身不依赖任何工具,写进任何对话框、任何 CI 的 issue 模板、任何 Agent 的 system prompt 都成立。工具只是让它复用起来更省事。
4.4 原则四:把上下文当预算,不是当硬盘
三条会直接影响账单的事实:
- 长上下文溢价:单次请求输入 >272K tokens 时,整次请求输入 2×、输出 1.5×。注意是"整次请求",不是"超出部分"------这意味着 273K 和 500K 的请求都在同一档,但 271K 和 273K 之间有一道断崖。
- 缓存读取 10 倍折扣 :
$1/1Mvs 新鲜输入$10/1M。Astra 相对 Sol 更贵,所以这个折扣的绝对价值比前代更高------把稳定的系统提示、大段参考资料、工具定义放在前缀并复用,收益显著。 - 压缩阈值 :跑大 monorepo 时把
auto_compact_token_limit显式设为约 200K,避开 272K 溢价线。
下面是可以嵌进调用层的预算守卫:
python
# context_budget.py
LONG_CONTEXT_PREMIUM = 272_000 # 超过则整次请求输入 2x、输出 1.5x
MAX_INPUT = 922_000
SOFT_COMPACT = 200_000 # 建议的自动压缩阈值
# 标准价(美元 / 1M tokens);长上下文溢价后按倍率放大
PRICE = {
"in": 10.0, "out": 50.0,
"cached_read": 1.0, "cached_write": 12.50,
}
def estimate_cost_usd(prompt_tokens: int,
cached_tokens: int,
completion_tokens: int,
fast: bool = False,
batch: bool = False) -> dict:
"""估算单次请求成本,并对溢价档给出显式告警。"""
fresh = max(prompt_tokens - cached_tokens, 0)
mult_in, mult_out = (2.0, 1.5) if prompt_tokens > LONG_CONTEXT_PREMIUM else (1.0, 1.0)
cost = (
fresh / 1e6 * PRICE["in"] * mult_in
+ cached_tokens / 1e6 * PRICE["cached_read"] * mult_in
+ completion_tokens / 1e6 * PRICE["out"] * mult_out
)
if fast:
cost *= 2.0 # Fast mode: 2x 价格
if batch:
cost *= 0.5 # Batch / Flex: 5 折
warnings = []
if prompt_tokens > LONG_CONTEXT_PREMIUM:
warnings.append(
f"触发长上下文溢价(>{LONG_CONTEXT_PREMIUM}):本次输入按 2x、输出按 1.5x 计价。"
f"建议压到 {LONG_CONTEXT_PREMIUM} 以下,或把稳定前缀改为缓存复用。"
)
if prompt_tokens > SOFT_COMPACT:
warnings.append(f"超过建议压缩阈值 {SOFT_COMPACT},考虑显式压缩或拆分请求。")
if prompt_tokens > MAX_INPUT:
warnings.append(f"超过最大输入 {MAX_INPUT},请求会被拒绝。")
return {
"usd": round(cost, 6),
"premium": mult_in > 1.0,
"warnings": warnings,
}
def should_compact(prompt_tokens: int, hard_limit: int = SOFT_COMPACT) -> bool:
"""在组装请求前调用:决定是否先压缩再发。留出 10% 余量防抖。"""
return prompt_tokens > hard_limit * 0.9
if __name__ == "__main__":
print(estimate_cost_usd(260_000, 240_000, 4_000)) # 未触发溢价 + 大量缓存命中
print(estimate_cost_usd(280_000, 0, 4_000)) # 触发溢价 + 无缓存
运行这两个例子你会看到一个很直观的对比:同样是 26-28 万 token 的输入,缓存命中与否加上溢价触发与否,成本可以差出一个数量级。上下文治理不是优化,是成本控制的第一道闸门。
顺带一个容易被忽略的事实:长参考资料放进 Skill 的 references/ 几乎是零成本(按需加载),放进 AGENTS.md / CLAUDE.md 则是每次会话都烧 token------因为后者在每个任务上都全量生效。改个 typo 也要为它付费。
4.5 原则五:最小权限是产品需求,不是安全团队的事
Astra 是 OpenAI 首个在 Preparedness Framework 下网络安全能力达到 Critical(关键级) 的模型:有合适工具和权限时,能在防护严密的系统中找到未知漏洞并开发可利用方法,无需人工逐步指导。评估期间它发现并使用了 2 个此前未知的零日漏洞,OpenAI 称已向维护者披露。
因此:Astra 对 Enterprise 账号默认关闭,管理员必须在 OpenAI 管理后台显式开启。这不是产品偷懒,是风险等级的必然结果。
普通用户拿到的不是无限制的攻击工具:公开版会拒绝生成 PoC exploit 等高级攻击任务;完整防御能力走审核制的 Daybreak 计划。每个使用工具的外部 Astra 推理都施加 misalignment monitoring,被阻断的 API 任务会停止。
但平台护栏不能替代应用内控制。Agent 架构至少要具备下面这些:
| 控制项 | 具体要求 | 落地形态 |
|---|---|---|
| 默认只读 | 未显式授权前,Agent 无写/删/部署/外发权限 | 工具白名单 + 只读沙箱 |
| 分级授权 | 写、删、部署、外发消息分别单独授权,不打包 | 权限位 / scope |
| 短时效凭证 | 数据库、云账号、生产系统用短时效凭证 | STS / 临时 token |
| 人工审批 | 不可逆动作前必须人工确认,展示目标、范围、预期变更 | 审批网关 + dry-run 预览 |
| 事件记录 | 工具调用、实际 diff、拒绝记录、人工覆盖全部留痕 | 结构化审计日志 |
| 超时与状态持久化 | 安全系统可能因"无界递归派生子任务"而终止执行 | 检查点 + 断点恢复 |
这里有一条重要警示 :OpenAI 的 system card 披露,Astra 比 Sol 更难监控------它对自身书面推理有更强的控制力,刻意逃避时更难被发现。OpenAI 将提升可监控性列为持续研究重点。
结论是那句反直觉的话:更对齐 ≠ 更容易监管。 越权率从 48.2% 降到 0%,不代表你可以降低审计强度;恰恰相反,因为检测难度上升,你需要更依赖外部行为证据(实际 diff、工具调用日志),而不是依赖模型的自我陈述。
还有一个会打断合法工作的机制:安全系统会监测"自我繁殖式 agent 行为"(无界递归派生子任务),并在检测到风险循环时终止执行。这会打断合法的复杂工作流------所以生产系统必须实现超时处理与状态持久化,以恢复部分成果。这不是可选项。
4.6 原则六:长程任务靠外部编排,不靠模型自己记
这是把 2.2 节那句引文落到实操的部分。Manager Loop 的做法(Matt Shumer,社区实测):
- 启动一个 manager agent,讨论目标,让它生成一份庞大的 to-do checklist,再拆成 phases
- manager 在独立线程 派生第二个 agent(implementer,注意是完整独立 agent 而不是 sub-agent),两者可互相发消息
- manager 进
/goal模式,对每个 phase 向 implementer 下达/goal Complete phase one completely, extremely well,implementer 做完才回消息,然后进入下一 phase,全程自主
几个细节值得单独摘出来:
- 措辞 :要求每个 phase 做到
extremely well而不是perfectly。"perfect" 会把模型重新推回细节里。 - 进度可视化 :让 implementer 维护一个 HTML 页面,勾选 checkbox 并显示"已完成数随时间"的图表;提示
if you haven't ticked a box in X amount of time, move on。这个设计很妙------它让模型自己看见"我很久没进展了,该往下走",把抽象的停滞变成可观测信号。 - 并发 :把子 agent 上限从 4 提到 16(他自己提到过 96,但也说这是过度且极贵)。提高上限不等于它会自动使用,有时需要显式鼓励它多用 sub-agent。
他自己承认的两个未修复问题,我认为比方法本身更有价值:
- 上下文膨胀:implementer 的上下文跨 phase 累积,后期仍会退化。修法是每个 phase 起一个新的 implementer 并做书面交接,或让新 implementer 读前一个的 traces。
- 计划漂移:计划在工作开始前写好,必然有部分是错的。应允许 implementer 提出修改、由 manager 裁决(或反过来)。
替代路径说明 :Manager Loop 用的是 Codex 的 /goal 模式与独立线程。如果你没有这些能力,等价的最小实现是:一个手写 YAML/JSON 任务清单 + 一个"每次只处理一个 phase、做完写回状态文件"的循环脚本 + 一个外部进度看板。编排层是必需品 ,特定的 /goal 语法只是加速带。
状态文件 / 进度看板 implementer agent(独立线程) manager agent 人(定义目标与验收) 状态文件 / 进度看板 implementer agent(独立线程) manager agent 人(定义目标与验收) #mermaid-svg-s4fCHe1ktxvhjWEY{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-s4fCHe1ktxvhjWEY .error-icon{fill:#552222;}#mermaid-svg-s4fCHe1ktxvhjWEY .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-s4fCHe1ktxvhjWEY .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-s4fCHe1ktxvhjWEY .marker{fill:#333333;stroke:#333333;}#mermaid-svg-s4fCHe1ktxvhjWEY .marker.cross{stroke:#333333;}#mermaid-svg-s4fCHe1ktxvhjWEY svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-s4fCHe1ktxvhjWEY p{margin:0;}#mermaid-svg-s4fCHe1ktxvhjWEY .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-s4fCHe1ktxvhjWEY text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-s4fCHe1ktxvhjWEY .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-s4fCHe1ktxvhjWEY .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-s4fCHe1ktxvhjWEY #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-s4fCHe1ktxvhjWEY .sequenceNumber{fill:white;}#mermaid-svg-s4fCHe1ktxvhjWEY #sequencenumber{fill:#333;}#mermaid-svg-s4fCHe1ktxvhjWEY #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-s4fCHe1ktxvhjWEY .messageText{fill:#333;stroke:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-s4fCHe1ktxvhjWEY .labelText,#mermaid-svg-s4fCHe1ktxvhjWEY .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .loopText,#mermaid-svg-s4fCHe1ktxvhjWEY .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-s4fCHe1ktxvhjWEY .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-s4fCHe1ktxvhjWEY .noteText,#mermaid-svg-s4fCHe1ktxvhjWEY .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-s4fCHe1ktxvhjWEY .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-s4fCHe1ktxvhjWEY .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-s4fCHe1ktxvhjWEY .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-s4fCHe1ktxvhjWEY .actorPopupMenu{position:absolute;}#mermaid-svg-s4fCHe1ktxvhjWEY .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-s4fCHe1ktxvhjWEY .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-s4fCHe1ktxvhjWEY .actor-man circle,#mermaid-svg-s4fCHe1ktxvhjWEY line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-s4fCHe1ktxvhjWEY :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 若长时间未勾选新 checkbox 则视为停滞,强制进入下一 phase alt 计划需要修改 loop 每个 phase 每 phase 可换新的 implementer 以规避跨 phase 上下文膨胀 描述目标,要求产出 to-do checklist 拆分为 phase 1..N 写入计划与初始状态 派生独立 implementer(非 sub-agent) /goal Complete phase N completely, extremely well 自主执行(工具调用 / 自检 / 修复) 勾选 checkbox,更新完成数曲线 阶段完成汇报(含证据) 校验完成标准;必要时裁决计划变更 提出计划漂移与修改建议 更新计划(记录裁决理由) 交付 + 全量事件记录与实际 diff
五、补齐那层缺失的 AI 工程化能力:五层能力栈
现在把第三节的四个上位概念,映射成一套可施工的结构。
5.1 五层模型与各层选型
| 层 | 机制(例) | 本质 | 加载时机 | 约束力 | 典型内容 |
|---|---|---|---|---|---|
| 知识层 | CLAUDE.md / AGENTS.md | 持久指令文件 | 每次会话启动全量加载 | 软约束(上下文引导) | 构建命令、编码约定、架构事实 |
| 强制层 | Hooks | 生命周期事件上的 shell / HTTP 处理器 | 事件触发 | 硬约束(代码强制执行) | 拦截危险命令、提交前跑 lint |
| 流程层 | Skills | 按需加载的流程文档 | 被调用时才加载正文 | 软约束 | 部署流程、代码审查清单 |
| 分工层 | Subagents | 独立上下文的专职助手 | 被委派时启动 | 可限定工具与模型 | 代码探索、批量审计 |
| 连接层 | MCP | 外部工具 / 数据源接入协议 | Tools 启动时批量注册进 system prompt | --- | GitHub、数据库、内部系统 |
一句话选型口诀,值得背下来:
该知道的写 CLAUDE.md,必须发生的写 Hook,反复照做的做 Skill,不想污染主上下文的给 Subagent。
#mermaid-svg-cZzGM09vKy7GsJbc{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-cZzGM09vKy7GsJbc .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-cZzGM09vKy7GsJbc .error-icon{fill:#552222;}#mermaid-svg-cZzGM09vKy7GsJbc .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-cZzGM09vKy7GsJbc .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-cZzGM09vKy7GsJbc .marker{fill:#333333;stroke:#333333;}#mermaid-svg-cZzGM09vKy7GsJbc .marker.cross{stroke:#333333;}#mermaid-svg-cZzGM09vKy7GsJbc svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-cZzGM09vKy7GsJbc p{margin:0;}#mermaid-svg-cZzGM09vKy7GsJbc .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-cZzGM09vKy7GsJbc .cluster-label text{fill:#333;}#mermaid-svg-cZzGM09vKy7GsJbc .cluster-label span{color:#333;}#mermaid-svg-cZzGM09vKy7GsJbc .cluster-label span p{background-color:transparent;}#mermaid-svg-cZzGM09vKy7GsJbc .label text,#mermaid-svg-cZzGM09vKy7GsJbc span{fill:#333;color:#333;}#mermaid-svg-cZzGM09vKy7GsJbc .node rect,#mermaid-svg-cZzGM09vKy7GsJbc .node circle,#mermaid-svg-cZzGM09vKy7GsJbc .node ellipse,#mermaid-svg-cZzGM09vKy7GsJbc .node polygon,#mermaid-svg-cZzGM09vKy7GsJbc .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-cZzGM09vKy7GsJbc .rough-node .label text,#mermaid-svg-cZzGM09vKy7GsJbc .node .label text,#mermaid-svg-cZzGM09vKy7GsJbc .image-shape .label,#mermaid-svg-cZzGM09vKy7GsJbc .icon-shape .label{text-anchor:middle;}#mermaid-svg-cZzGM09vKy7GsJbc .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-cZzGM09vKy7GsJbc .rough-node .label,#mermaid-svg-cZzGM09vKy7GsJbc .node .label,#mermaid-svg-cZzGM09vKy7GsJbc .image-shape .label,#mermaid-svg-cZzGM09vKy7GsJbc .icon-shape .label{text-align:center;}#mermaid-svg-cZzGM09vKy7GsJbc .node.clickable{cursor:pointer;}#mermaid-svg-cZzGM09vKy7GsJbc .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-cZzGM09vKy7GsJbc .arrowheadPath{fill:#333333;}#mermaid-svg-cZzGM09vKy7GsJbc .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-cZzGM09vKy7GsJbc .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-cZzGM09vKy7GsJbc .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-cZzGM09vKy7GsJbc .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-cZzGM09vKy7GsJbc .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-cZzGM09vKy7GsJbc .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-cZzGM09vKy7GsJbc .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-cZzGM09vKy7GsJbc .cluster text{fill:#333;}#mermaid-svg-cZzGM09vKy7GsJbc .cluster span{color:#333;}#mermaid-svg-cZzGM09vKy7GsJbc div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-cZzGM09vKy7GsJbc .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-cZzGM09vKy7GsJbc rect.text{fill:none;stroke-width:0;}#mermaid-svg-cZzGM09vKy7GsJbc .icon-shape,#mermaid-svg-cZzGM09vKy7GsJbc .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-cZzGM09vKy7GsJbc .icon-shape p,#mermaid-svg-cZzGM09vKy7GsJbc .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-cZzGM09vKy7GsJbc .icon-shape .label rect,#mermaid-svg-cZzGM09vKy7GsJbc .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-cZzGM09vKy7GsJbc .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-cZzGM09vKy7GsJbc .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-cZzGM09vKy7GsJbc :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 不允许,必须发生
允许,但每次都要知道
小且稳定
大或按需
是
否
是
否
收到一个需求
这条规则
允许被模型跳过吗?
强制层:Hook
例:Claude Code Hooks / pre-commit / CI 卡口
内容量大吗?
知识层:AGENTS.md / CLAUDE.md
控制在 200 行内
流程层:Skill
description 常驻,正文按需加载
子任务会用搜索结果/日志/文件
淹没主对话,且之后不再引用?
分工层:Subagent
独立上下文,可路由到便宜模型
留在主上下文
需要接外部系统
(数据库 / GitHub / 内部 API)?
连接层:MCP
只装真正需要的 server
不引入额外连接
验收:让它证明而不是声称
tests / hooks / linters 自动跑
图里的工具名都加了"例:",就是提醒你:这棵树判断的是机制,不是品牌。 没有 Claude Code 的 Hooks,你用 pre-commit + CI 实现同样的硬约束;区别只在于反馈时机:
| 反馈时机 | 实现(例) | 优点 | 缺点 |
|---|---|---|---|
| 边写边拦 | Claude Code Hooks / PreToolUse | 反馈最早,模型可立即纠正 | 依赖特定工具;配置成本 |
| 提交后拦 | git pre-commit / pre-push | 工具无关,团队统一 | 错误已经写完才被发现 |
| CI 拦 | GitHub Actions / GitLab CI | 最权威,无法绕过 | 反馈最慢,往返成本高 |
5.2 知识层:AGENTS.md / CLAUDE.md 该写什么、不该写什么
三条硬规则:
- 单文件控制在 200 行内。官方建议,过长会显著降低遵循度。
- 指令要具体可验证。"用 2 空格缩进"优于"格式规范"。
- 子目录的 CLAUDE.md 不在启动时加载 ,而是读到该目录文件时按需载入------这是 monorepo 分区的基础。
.claude/rules/+ paths frontmatter 也可按路径加载。
还有一条常被误解:@import 不省 token。它只是让维护更方便,被引入的内容照样进上下文。
参考 Provencher 的对照:
- BAD :
Before making any change, read the full architecture doc, the API reference, and the testing guide. After every change, run the full test suite and wait for explicit approval before continuing to the next step. - GOOD :
The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.
BAD 版本有两个问题:一是强制每次改动前读三份文档,与任务大小无关(改个 typo 也要付这份税);二是要求每步等待批准,这是典型的"补偿旧模型判断不足"的边界,对 Astra 会主动降低吞吐。GOOD 版本做了两件事:给出安全事实 (用即用型 fixture,无生产访问)从而让"自动跑测试"变得合理,以及明确授权一条已知安全、可重复的 workflow。
一份精简版模板:
markdown
# AGENTS.md
## 构建与测试
- 安装:`pnpm install`(Node 20+)
- 单元测试:`pnpm test -- <path>`(使用即用型 fixture,无生产环境访问)
- 类型检查:`pnpm tsc --noEmit`
- lint:`pnpm lint`
**已授权自动执行**:修复由本次改动引起的测试失败并重跑受影响的测试,
无需逐步请示。生产部署、破坏性数据库迁移、有计费后果的外部 API 调用仍需人工确认。
## 编码约定
- TypeScript strict;缩进 2 空格;单引号
- 导出函数必须有 JSDoc;公共 API 变更需同步 `docs/api.md`
- 禁止在 `migrations/published/` 下修改已发布文件
## 架构事实(只写不会频繁变的)
- `apps/api`:Fastify 服务,端口 3000
- `packages/core`:无副作用纯逻辑,**不允许引入任何 IO**
- `packages/adapters`:外部系统适配层,唯一允许发起网络请求的地方
## 不要写在这里
- 具体功能的使用教程(放 Skill)
- 长篇 API 参考(放 Skill 的 references/,按需加载)
- 为纠正某个旧模型毛病而设的临时规则(每次升级都要重审)
替代路径说明 :任何支持"仓库级系统提示"的工具都有等价物(Cursor 的 Rules、Copilot 的 instructions、自建 Agent 的 system prompt 拼装)。完全没有这个概念时,就把这份文件的内容拼进每次请求的前缀------代价是无法利用前缀缓存,成本更高。所以它是加速带,不是必需品。
5.3 强制层:Hooks 是唯一的硬约束
软约束(写在文档里)模型可以忽略;硬约束(写在代码里)模型绕不过去。这是唯一一层能给出确定性保证的机制。
先记死 exit code 语义,这是高频踩坑点:
exit 0= 放行exit 2= 阻断(stderr 会反馈给模型)exit 1不阻断,只是非阻断错误,执行照常继续
想拦截危险操作,必须 exit 2,或返回 JSON 的 permissionDecision: "deny"。写成 exit 1 等于没拦。
常用事件:
| 事件 | 能力 | 典型用途 |
|---|---|---|
PreToolUse |
可阻断 | 拦截危险命令(如 rm -rf、git push --force、直连生产库) |
PostToolUse |
可反馈 | 写文件后自动跑格式化 / lint |
UserPromptSubmit |
可阻断 / 清除 | 注入上下文、拦截敏感输入 |
Stop |
可阻止停止 | 确保测试通过才收工 |
SubagentStart / SubagentStop |
观察 | 子代理启停记录 |
PreCompact / PostCompact |
前者可阻断 | 压缩前后做状态落盘 |
SessionStart / SessionEnd |
观察 | 会话级初始化与清理 |
处理器有 5 种:command、http、mcp_tool、prompt、agent。
一个实际能用的 PreToolUse 拦截脚本:
bash
#!/usr/bin/env bash
# .claude/hooks/block-dangerous.sh
# PreToolUse 钩子:拦截高危命令。
# 退出码语义:0 = 放行,2 = 阻断(stderr 反馈给模型),1 = 非阻断错误(不会拦住!)
set -uo pipefail
payload="$(cat)"
tool="$(printf '%s' "$payload" | jq -r '.tool_name // "unknown"')"
cmd="$(printf '%s' "$payload" | jq -r '.tool_input.command // .tool_input.file_path // ""')"
deny() {
# 阻断必须 exit 2,并把原因写进 stderr ------ 这段文本会回到模型上下文
echo "BLOCKED: $1" >&2
echo "如果你确实需要执行,请停下来向用户说明并等待人工确认。" >&2
exit 2
}
# 1) 破坏性删除
if printf '%s' "$cmd" | grep -Eq '(^|[^a-zA-Z])rm[[:space:]]+.*(-rf|-fr)([[:space:]]|$)'; then
deny "检测到高危删除命令:${cmd}"
fi
# 2) 强制推送到受保护分支
if printf '%s' "$cmd" | grep -Eq 'git[[:space:]]+push[[:space:]]+.*(--force|-f)([[:space:]]|$)' \
&& printf '%s' "$cmd" | grep -Eq '(main|master|release)'; then
deny "禁止向受保护分支强制推送:${cmd}"
fi
# 3) 直连生产数据库
if printf '%s' "$cmd" | grep -Eiq '(psql|mysql)[[:space:]].*(prod|production)'; then
deny "禁止直接连接生产数据库:${cmd}"
fi
# 4) 越权写入受保护路径
case "$cmd" in
*/migrations/published/*|*.env*|*/.git/*)
deny "受保护路径不允许写入:${cmd}" ;;
esac
exit 0
配置:
json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Write|Edit",
"command": "bash .claude/hooks/block-dangerous.sh"
}
],
"Stop": [
{
"matcher": "",
"command": "bash .claude/hooks/require-green-tests.sh"
}
]
}
}
Stop 事件那个钩子值得单独说------它能阻止模型停止。用途是确保测试通过才收工,把"让它证明而不是声称"变成硬约束。Agent 可以说 100 行改动做完了但一个测试没碰;有了 Stop 钩子,它停不下来。
配套的 require-green-tests.sh 核心逻辑(退出 2 表示"不许停,继续修"):
bash
#!/usr/bin/env bash
# .claude/hooks/require-green-tests.sh
# Stop 钩子:工作区有未修复的测试失败时,阻止 agent 停止。
set -uo pipefail
if ! pnpm test --silent >/tmp/agent-test.log 2>&1; then
echo "测试未通过,不允许结束本次任务。请修复后重试。" >&2
tail -n 40 /tmp/agent-test.log >&2
exit 2 # 关键:必须是 2,exit 1 不会阻止停止
fi
if ! pnpm lint --silent >/tmp/agent-lint.log 2>&1; then
echo "lint 有告警,请修复后重试。" >&2
tail -n 20 /tmp/agent-lint.log >&2
exit 2
fi
exit 0
替代路径说明 :Hooks 是"边写边拦",反馈最早,但依赖特定工具。没有它时的等价实现是 git pre-commit(提交后拦)和 CI(最慢但无法绕过)。三者的区别只是反馈时机与绕过难度------Hooks 是加速带,CI 是必需品。即使你有 Hooks,CI 那一层也不能省,因为本地钩子可以被跳过。
5.4 流程层:Skills 用渐进披露换上下文
Skill 的核心机制是**渐进披露(progressive disclosure)**三层:
description常驻上下文(决定何时触发)- 正文在被调用时才加载
references/中的长资料按需读取
关键 frontmatter 字段:
| 字段 | 作用 |
|---|---|
name |
标识 |
description |
决定何时触发,常驻上下文,最需要打磨 |
disable-model-invocation |
true = 仅限手动触发,适合有副作用的流程 |
allowed-tools |
限定可用工具 |
context: fork |
在独立子代理中执行 |
model |
可路由到便宜模型 |
一个高频反模式:装太多 skill 时,工具会为适配上下文而截断描述,反而更难选对。 所以 description 要从"anything related to a database"收窄成"database schema migrations specifically"。
对照(Provencher 原文):
markdown
# ❌ 不合格:范围过宽,会和一堆其他 skill 抢触发,且描述过长易被截断
---
name: database-helper
description: Use this skill whenever you're working with databases, schemas,
queries, migrations, ORMs, or anything data-related...
---
(正文几百行,从建表讲到查询优化)
markdown
# ✅ 合格:触发条件具体,正文聚焦,长资料外置
---
name: db-migration
description: Use when writing or reviewing a database schema migration file in
this repo (not for general queries or ORM usage).
allowed-tools: Read, Grep, Bash(psql), Edit
---
## 前置检查
1. 确认目标环境:`psql "$DATABASE_URL" -c 'select version()'`
2. 确认 `migrations/published/` 下无同名文件
## 步骤
1. 在 `migrations/` 下新建 `NNNN_<描述>.sql`(NNNN 取当前最大序号 +1)
2. 每个迁移必须同时包含 up 与 down 两段
3. 禁止在迁移中做全表重写,除非已确认表行数 < 100 万
## 完成标准
- `psql -f <file>` 在临时库上执行成功且 down 段可回滚
- `pnpm test -- packages/core` 全绿
## 详细约定
详见 references/migration-conventions.md(仅在本 skill 被触发后才需读取)
那个 not for general queries or ORM usage 的排除句很重要------负例和正例一样重要。
5.5 分工层:Subagents 与并行隔离
使用判据(这是官方给出的,很精确):当子任务会用搜索结果、日志、文件内容淹没主对话,而你之后不会引用这些内容时,就给 Subagent。它在自己窗口干完,只带结论回来。
探索类任务路由到便宜模型是官方明示的省钱手段------探索本身不需要最强推理,需要的是大窗口和廉价吞吐。
并行隔离用 git worktrees:让多个 agent 会话在不同分支并行而互不污染文件状态,绑到同一个 git tag 基线保证可比。
bash
# 为三个并行 agent 建立隔离工作区,统一基线
BASE_TAG=$(git tag --points-at HEAD | head -n1)
[ -z "$BASE_TAG" ] && { echo "请先打一个基线 tag"; exit 1; }
for i in 1 2 3; do
git worktree add "../wt-agent-$i" -b "agent/task-$i" "$BASE_TAG"
echo "worktree ../wt-agent-$i 已就绪(基线 $BASE_TAG)"
done
# 各自完成后,逐个评审实际 diff,而不是听汇报
for i in 1 2 3; do
echo "===== agent-$i ====="
git -C "../wt-agent-$i" diff "$BASE_TAG"...HEAD --stat
done
# 清理
# git worktree remove ../wt-agent-1 --force
注意最后那句命令的意图:评审实际 diff,而不是听汇报。这对应"让它证明而不是声称"------Agent 可以说改完了但一个测试没碰,diff 不会撒谎。
更高风险的改动还可以用跨模型评审:让另一个模型 review diff。这不是玄学,是承认单一模型存在系统性盲区。
替代路径说明:Subagent 是加速带。没有这个机制时,等价做法是人工拆分任务 + 多个独立会话 + 你自己在中间做汇总。慢,但可行。
5.6 连接层:MCP 三原语与"只装需要的"
MCP 三原语的区别决定了它们的成本特征:
| 原语 | 谁发起 | 加载方式 | 成本特征 | 典型用途 |
|---|---|---|---|---|
| Tools | 模型调用 | 启动时批量注册进 system prompt | 每个都占上下文,不论用不用 | GitHub 操作、数据库写入(唯一能修改外部状态的通道) |
| Resources | 应用/模型按需拉取 | 惰性,量大不占 prompt | 几乎零常驻成本 | 150+ 张表的 schema、文档库 |
| Prompts | 用户/应用选择 | Server 端预定义模板 | 低 | 预置的可参数化任务模板 |
关键区别:Tools 是唯一能修改外部状态的通道,也是唯一在启动时就占上下文的。所以那条反模式必须反复强调:
只装真正需要的------不是每个可用的 MCP server,不是共享库里的每个 skill。每加载一个都在花上下文,不论这次会话用不用得上。
如果你有 150 张表的 schema 要暴露,做成 Resources 而不是 150 个 Tool------这是成本差一个数量级的选择。
自建 MCP Server 还有一项常被忽略的成本:它是一份要长期维护的软件资产。协议会变、上游 API 会变、认证方式会变。装第三方 server 之前先问一句:这个 server 谁在维护?上一个 commit 是什么时候?
5.7 组合矩阵:1 个工具、2 个工具、3 个及以上怎么排
不给固定结论,给决策依据。判断顺序是固定的:
- 先列出你的高频任务类型(不是工具功能,是你实际要做的事)
- 给每类任务标注三个属性:是否需要多步工具调用 / 预估上下文量级 / 错了的代价
- 按属性分配到模型档位(用 4.1 节的路由表)
- 最后才决定用哪个工具承载,且一个工具只承接它能承接的那部分
| 你手上的工具数 | 分工原则 | 具体排法 | 最容易犯的错 |
|---|---|---|---|
| 只有 1 个 | 不要横向扩展,纵向挖深 | 把知识层(仓库指令)+ 流程层(2-3 个高频 Skill)建扎实;硬约束交给 git hooks + CI | 急着装第二个工具,结果两个都是半配置状态 |
| 有 2 个 | 按"交互模式"而非"能力高低"分工 | 一个承接同步、短、需要即时反馈的(补全/单文件修改);一个承接异步、长、可验收的(跨文件重构/批量迁移)。两者的知识层文件共用同一份,避免口径分裂 | 两个工具各配一份仓库指令,约定逐渐漂移,最后互相打架 |
| 有 3 个及以上 | 按"层"分工,不是按"任务"分工 | 一个主执行(日常开发)+ 一个长程编排(跑 phase 级任务)+ 一个评审/旁观(跨模型 review diff)。三者共享同一份状态文件与事件记录 | 每个工具都接一遍同样的 MCP,上下文重复付费,且权限口径不一致 |
三条通用判断依据,比任何具体组合都重要:
- 共享状态优先于共享工具:多个工具之间要共享的是任务状态、完成标准、事件记录,不是 MCP 连接。
- 知识层必须单一真相源:无论几个工具,仓库约定只有一份,放在版本控制里。
- 硬约束放在最外围:能被本地跳过的约束,必须有 CI 兜底。
六、升级 GPT-6 后必须重跑的一次审计(8 条清单)
Provencher 的原文清单,每条都问同一个问题:我当前运行的模型还需要这条吗? 建议在每次模型升级时重跑,不只在升 Astra 时。
| # | 审计项 | 为什么 | 怎么改 |
|---|---|---|---|
| 1 | Skills:有没有 description 在干超出"指明具体触发条件"的事? |
描述过长会在装多个 skill 时被截断,反而降低命中率 | 缩短到一句话,只写触发条件 |
| 2 | Skills:根 SKILL.md 是路由,还是把整个工作流平铺在里面? |
平铺会一次性吃掉大量上下文 | 拆分成路由 + 子文档 / references/ |
| 3 | Skills:有没有多个 skill 会在同一个任务上同时触发? | 触发冲突导致选择随机化 | 合并,或收窄各自的触发条件(加排除句) |
| 4 | AGENTS.md / CLAUDE.md:是否强制每次改动前读文档或生成 repo map,不论任务大小? | 改个 typo 也要付这份税,且与任务规模无关 | 删掉一刀切规则,改为按需 |
| 5 | AGENTS.md / CLAUDE.md:是否还在提醒模型跑它现在本来就会跑的测试? | 冗余提示占上下文,且暗示"可以不跑" | 删除该提示 |
| 6 | AGENTS.md / CLAUDE.md:是否至少明确授权了一条已知安全、可重复的 workflow(测试 / lint / 本地构建)? | 没有显式授权,模型会在这些地方停下来等确认 | 补一段"已授权自动执行",并给出安全事实依据 |
| 7 | 决策边界:有没有"必须先问"的规则,是因为旧模型表现不好才加的,而不是因为动作真的高风险? | 对 Astra 会主动降低吞吐,它会在你希望它继续的地方精确停下 | 重划范围而非删边界:保留真正高风险的(生产部署、破坏性迁移、有计费后果的外部 API 调用),解除那些只是补偿旧模型判断不足的 |
| 8 | 任务提示:每个多步提示是否都声明了"完成"的含义,包括模型是否应运行并检查自己的输出? | Sol 倾向于继续,Astra 倾向于暂停等 review;不定义 done 就会停错地方 | 用 4.3 的模板,强制 completion criteria 段 |
第 7 条特别提醒:修法是重划范围,不是删边界。 直接删掉所有 "ask first" 会引入真实风险;正确做法是逐条问"这条边界保护的是什么",只有答案是"旧模型太蠢"时才删。
一个可直接跑的检查脚本,用来做第一轮体检:
bash
#!/usr/bin/env bash
# audit-agent-config.sh ------ 模型升级后的配置体检(只读,不改任何文件)
# 用法:bash audit-agent-config.sh [仓库根目录]
set -uo pipefail
ROOT="${1:-.}"
cd "$ROOT" || exit 1
fails=0
warn=0
note() { printf ' %s\n' "$1"; }
fail() { printf '[FAIL] %s\n' "$1"; fails=$((fails+1)); }
wrn() { printf '[WARN] %s\n' "$1"; warn=$((warn+1)); }
ok() { printf '[ OK ] %s\n' "$1"; }
echo "=== 1. 常设指令文件行数(红线 200 行)==="
for f in AGENTS.md CLAUDE.md .cursorrules; do
[ -f "$f" ] || continue
n=$(wc -l < "$f" | tr -d ' ')
if [ "$n" -gt 200 ]; then fail "$f 共 ${n} 行,超过 200 行红线,遵循度会下降";
else ok "$f 共 ${n} 行"; fi
done
echo
echo "=== 2. 常设指令中的可疑模式 ==="
for f in AGENTS.md CLAUDE.md; do
[ -f "$f" ] || continue
grep -nEi 'wait for (explicit )?approval|ask (the user )?(for permission|first) before' "$f" \
| while IFS= read -r line; do wrn "$f: $line <-- 审计项 7:这是补偿旧模型的边界,还是真高风险?"; done
grep -nEi 'before (making )?any change' "$f" \
| while IFS= read -r line; do wrn "$f: $line <-- 审计项 4:与任务大小无关的一刀切规则"; done
done
echo
echo "=== 3. Skill description 长度(过长会在多选时被截断)==="
find . -name 'SKILL.md' -not -path '*/node_modules/*' 2>/dev/null | while read -r sf; do
desc=$(awk '/^---$/{c++; next} c==1' "$sf" | sed -n 's/^description:[[:space:]]*//p' | tr -d '\n')
len=${#desc}
name=$(basename "$(dirname "$sf")")
if [ "$len" -eq 0 ]; then fail "$sf 缺少 description(决定触发的关键字段)"
elif [ "$len" -gt 200 ]; then wrn "$name description ${len} 字符,偏长,建议收窄到具体触发条件"
else ok "$name description ${len} 字符"; fi
done
echo
echo "=== 4. 已废弃/不支持的参数残留 ==="
grep -rnE 'temperature|top_p|logprobs' --include='*.toml' --include='*.json' --include='*.py' \
--include='*.ts' --exclude-dir=node_modules . 2>/dev/null \
| while IFS= read -r line; do wrn "发现不支持的参数:$line"; done
grep -rn 'reasoning_effort' --include='*.toml' . 2>/dev/null | grep -E '"none"|none' \
| while IFS= read -r line; do fail "reasoning_effort=\"none\" 会被 API 层拒绝:$line"; done
echo
echo "=== 5. Hook 退出码语义(exit 1 不会阻断!)==="
find . -path '*hooks*' -name '*.sh' -not -path '*/node_modules/*' 2>/dev/null | while read -r h; do
if grep -qE '^\s*exit 1' "$h" && grep -qiE 'block|deny|禁止|BLOCKED' "$h"; then
fail "$h 中同时出现 'exit 1' 与拦截意图 ------ exit 1 不阻断,必须用 exit 2"
fi
done
echo
echo "=== 6. 是否显式授权了至少一条安全可重复 workflow ==="
for f in AGENTS.md CLAUDE.md; do
[ -f "$f" ] || continue
if grep -qEi '(run|running) (the )?tests|无需.*(请示|确认)|without asking' "$f"; then
ok "$f 包含自动执行授权"
else
wrn "$f 未发现显式授权(审计项 6)------ 模型会在测试/lint 处停下等你"
fi
done
echo
echo "----------------------------------------"
echo "FAIL: $fails WARN: $warn"
echo "提示:WARN 需要人工判断,FAIL 建议当次修掉。"
七、30 天从"会用"到"能稳定干完"的落地路径
四个阶段,每阶段有可验收的产出物和度量指标。没有度量的改进等于没改。
| 阶段 | 动作 | 产出物 | 度量指标 |
|---|---|---|---|
| 第 1 周:审计与减法 | 跑第六节的 8 条审计;删掉补偿旧模型的边界;收窄 Skill 描述;常设指令压到 200 行内 | 审计前后对照记录、精简后的 AGENTS.md | 常设指令行数、Skill description 平均长度、每任务平均人工干预次数 |
| 第 2 周:硬约束与流程资产化 | 把"必须发生"的规则升级为 Hook(PreToolUse 拦截 + Stop 卡测试);把反复照做的流程写成 Skill;CI 兜底 | 2-3 个 Hook、2-3 个 Skill、CI 卡口 | 被拦截的高危操作次数、CI 拦截率、"声称完成但没跑测试"的发生率 |
| 第 3 周:编排与并行 | 引入 Manager Loop 式分阶段执行;状态文件外置;git worktrees 并行隔离;超时与断点恢复 | 任务清单文件、进度看板、worktree 脚本 | 长任务完成率、中途停滞次数、平均恢复耗时 |
| 第 4 周:度量与路由 | 用真实生产请求抽样做 A/B;按 4.1 路由表分档;跟踪延迟与每次请求成本 | 路由配置、A/B 报告、成本看板 | 每次任务成本、端到端耗时、完成率、人工干预次数 |
几个执行建议:
- 第 1 周别急着加东西。减法比加法难,但收益最大。Provencher 的核心论点就是"新模型需要更少脚手架"。
- 第 2 周的 CI 不能省。即使本地 Hook 已经很全,CI 是唯一无法被本地跳过的层。
- 第 3 周的状态文件比编排逻辑更重要。计划可以错(计划漂移是已知未解问题),但状态必须可恢复。
- 第 4 周不要信通用基准。跟踪三个数就够了:延迟、每次请求成本、你自己任务上的输出质量。
关于额度:Astra 采用基于工作量的额度体系,Plus 由 3-30 条提高到 5-45 条,$100 档 Pro 由 15-150 提高到 25-225,$200 档 Pro 由 60-600 提高到 100-900。Astra 每百万 token 消耗约为 Sol 的 2.5 倍。把这些数字和你第 4 周的实测成本放一起看,才能判断该买哪个档。
八、踩坑清单
-
知识截止自述不可靠:直接问 Astra 自己的知识截止,它会答 "June 2024",而 model card 写的是 2026 年 4 月 30 日。→ 日期敏感事实必须钉到 model card 或外部来源,不要问模型自己。
-
272K 长上下文溢价 :单次请求输入超过 272K tokens 时,整次请求 输入 2×、输出 1.5×,不是只算超出部分。→ 把
auto_compact_token_limit设为约 200K,或在调用前做预算守卫。 -
temperature/top_p被静默忽略:Astra 不支持这两个参数,部分网关会静默丢弃而不是报错。→ 迁移时全局搜索并删除,别以为生效了。 -
reasoning_effort = "none"被拒 :最低档是low。→ 代码里凡是写着none的地方全部改成low。 -
企业版默认关闭 :Astra 对 Enterprise 账号默认关闭,管理员必须在 OpenAI 管理后台显式开启。→ 用了报
unrecognized model先查后台开关,别急着查 key。 -
Realtime / Assistants / fine-tuning / embeddings 全不支持:只有 Chat Completions、Responses、Batch。→ 依赖旧端点的应用需要重写接入层,不是改个 model ID 就行。
-
Skill 装太多反而更难选对:工具会为适配上下文而截断 description。→ 收窄描述,如从"anything related to a database"改成"database schema migrations specifically"。
-
Astra 会提前停下:Sol 倾向于继续,Astra 倾向于暂停等 review。→ 每条多步任务提示都必须显式写 completion criteria。
-
ask first过度会杀死吞吐:为纠正弱模型而加的边界,会让 Astra 在你希望它继续的地方精确停下。→ 重划范围而非删边界,只保留真正高风险的。 -
exit 1拦不住任何东西 :Hook 的退出码语义是 0 放行、2 阻断、1 不阻断。→ 想拦截必须exit 2或permissionDecision: "deny"。 -
安全监测会打断合法长任务:无界递归派生子任务会触发终止。→ 实现超时处理与状态持久化,保证能恢复部分成果。
-
可监控性下降:Astra 对自身书面推理有更强控制力,刻意逃避时更难被发现。→ 依赖外部行为证据(实际 diff、工具调用日志),不要依赖模型自我陈述。
-
Fast 模式文案误差:早期文档写 1.5×,实际是 2× 价格换最高 2.5× 速度,v0.153.2 才修正。→ 以最新文档为准,别信缓存的旧说明。
-
Mind2Web 的 1.9× 不能全算模型:该结果配了更新后的 Codex harness。→ 读到"提速 N 倍"先问:框架变了吗?
-
自建 MCP Server 是长期负债:协议、上游 API、认证方式都会变。→ 装之前先查维护活跃度,能用 Resources 就别用 Tools。
-
子 agent 上限提高 ≠ 会自动使用:把上限从 4 提到 16 之后,有时仍需显式鼓励它多用。→ 在任务提示里明确要求并行拆解。
-
@import不省 token:它只是方便维护,被引内容照样进上下文。→ 别用它来"优化"成本。 -
长资料放错位置 :放进 AGENTS.md 每次会话都烧钱,放进 Skill 的
references/几乎零成本。→ 按加载时机决定存放位置。 -
全量切换新模型:HLE 这一项 Astra 是退步的(57.2% vs 65.0%)。→ 必须在自己的任务集上 A/B 再切。
-
把官方演示当自家 workload:13 分 15 秒 vs 20 秒的对比来自官方演示。→ 演示选的必然是最有利场景,实测才是你的数。
九、总结:分水岭不在会不会用,在能不能稳定干完
回到开头那句话。Brockman 说"欢迎来到 AGI 时代",然后自己承认 AGI 是个灰色模糊的概念。这个自我修正比那句口号重要得多。
对开发者而言,这一代真正发生的变化可以压缩成一句:模型的计价单位从"回答一个问题"变成了"交付一件做完的事"。 而交付这件事,模型自己不负责。
四个维度的跃升------长程自主执行、长上下文与可检索记忆、对齐与边界遵守、推理与专业工作------每一个都在把能力边界往外推,同时把工程难度往你这边挪。越权率从 48.2% 到 0%,让"自动化 + 授权"进入可讨论范围;但可监控性下降又要求你把审计强度提上去。这两件事同时为真。
所以那三个让人焦虑的现象(工具只当补全用、MCP / Hooks / Sub-agent 配不起来、自建 Agent 反复推倒重来),解法从来不是再找一个更强的工具或者更好的 Prompt。它们的上位概念分别是:缺少任务---能力映射的路由意识、把模型当问答引擎而非执行引擎、没有分清知识/纪律/流程/分工四层、状态与知识没有外置。
这四层补上了,你用哪个工具、哪个模型,都只是参数。
最后那句引文值得再读一遍:外部编排结构,而不是模型原始能力,撑起了那次运行。
AI 时代真正的分水岭,从来不是"会不会用 AI",而是------能不能让 AI 稳定地把事干完。
参考资料
- OpenAI 官方 GPT-6 Astra 发布公告与 model card(2026-09-03 发布,2026-09-05 上线 API 与 Pro/Enterprise/Business Premium;context 1,050,000 / max input 922,000 / max output 128,000;知识截止 2026-04-30)
- OpenAI GPT-6 Astra System Card(Preparedness Framework 网络安全 Critical 评级;越权边界评测;可监控性下降披露;错位率与意外行为率数据)
- OpenAI 官方定价页与长上下文溢价说明(
$10/$50、缓存读取$1、缓存写入$12.50、>272K 溢价 2×/1.5×、Fast 2× 价格、Batch/Flex 5 折) - OpenAI 官方 computer-use 集成指南(沙箱代码执行
exec_py/exec_js优于逐原子动作;默认 viewport 1440×900) - Eric Provencher(OpenAI Codex DX),《Rethinking skills and prompts for GPT-6 Astra》,2026-09-05(8 条审计清单与四组 Before/After)
- Matt Shumer,Manager Loop 长程任务编排实践与复盘(含"extremely well vs perfectly"、进度可视化、两个未解问题)
- Dominik Kundel(OpenAI DevX),关于旧 video-editing skills 妨碍 Astra 的实测观察
- Anthropic Claude Code 官方文档:Hooks(事件与退出码语义)、Agent Skills、Subagents、MCP、CLAUDE.md 最佳实践
- Codex CLI 变更记录:v0.153.1 起支持 API 配置(不在会话内模型选择器显示)、v0.153.2 修正 Fast 档文案
- 腾讯开发者社区 / 阿里云开发者社区关于 CLAUDE.md、Hooks、Skills、Subagents、MCP 四类机制选型与落地实践的相关文章
注:链接以各官方发布页与文档站为准,本文不附具体 URL 以免失效。基准数据均引自上述官方或业界公开评测。