先看结果
文末有封装好的一键Skill，直接发给你的Codex即可自动优化瘦身。
我对这套系统做了一次实际瘦身。结果不是模糊的“感觉快了”，而是四组可以复核的数据：
| 指标 | 优化前 | 优化后 | 降幅 |
|---|---|---|---|
| 指令资产体积 | 147.9 KB | 30.8 KB | 79.2% |
| 强约束数量 | 92 条 | 14 条 | 84.8% |
| 典型写作路径负载 | 70.5 KB | 21.0 KB | 70.2% |
| 典型路径静态指令 Token | 20,411 | 4,897 | 76.0% |
 |
GPT-6 Astra 发布后，大家普遍的感受是：模型明明更强，额度却掉得更快。
新模型“贵”是一方面，OpenAI 针对这个问题亲自下场给出了官方的优化建议。
总结一句话：新模型已经不需要过度沉重的旧结构脚手架来约束，你构建的系统需要做精简升级。
官方文档：Rethinking skills and prompts for GPT-6 Astra
我读了官方文档，简单总结如下
1. 精简与重构 Skills
精准缩短描述：Skill 的描述应尽量简短并明确限定触发场景，避免因泛化描述（如“只要涉及数据库就触发”）而导致模型盲目加载无关上下文，或因描述过长被截断。
采用渐进式披露（Progressive Disclosure）：将根文档作为最小路由（Router），仅按需引导模型查阅具体的脚本或子文档，减少上下文消耗。
避免过度微观管理：新模型对语境和模糊意图的理解力提升，老旧、机械的步骤清单反而会限制模型发挥。
2. 更新与精简 AGENTS.md
按需引导而非强制阅读：移除“每次修改前阅读所有架构文档/全仓地图”等硬性规则，改为针对特定任务做上下文引用。
精简自动化测试指令：GPT-6 Astra 已具备主动测试与自我纠错的能力，过度的提醒反而会导致冗余测试。
调整决策边界与权限（Decision Boundaries）
Astra 的对齐和安全判断能力大幅提高，若保留过去针对旧模型设置的严苛审批规则，可能导致它过度谨慎、频频停下等待人工确认。针对安全的本地流程，应明确下放执行权限。
3. 明确任务完成定义与持久度（Persistence）
- 相比于 GPT-5.6 Sol 的长程自驱动，Astra 在第一轮实现后容易过早停下等待复核。用户需在 Prompt 中明确“完成”的定义（如包含运行、排查、修复失败等全流程），推动其彻底完成任务。
实测：内容系统大瘦身，成果显著
于是我按照官方的指导，对自己的创作系统做了一次优化升级。
真正把自己的内容创作系统拆开后才发现，问题有一部分根本不在模型，而在模型开始工作之前，Agent 已经替我重复支付了四笔隐形开销：常驻指令、按需文档、工具回传和错误的模型路由。
我对这套系统做了一次实际瘦身。结果不是模糊的“感觉快了”，而是四组可以复核的数据：
| 指标 | 优化前 | 优化后 | 降幅 |
|---|---|---|---|
| 指令资产体积 | 147.9 KB | 30.8 KB | 79.2% |
| 强约束数量 | 92 条 | 14 条 | 84.8% |
| 典型写作路径负载 | 70.5 KB | 21.0 KB | 70.2% |
| 典型路径静态指令 Token | 20,411 | 4,897 | 76.0% |
这里必须把口径说清楚：76% 是用 o200k tokenizer 估算的典型写作路径静态指令 Token 降幅，不是账户总额度减少 76%。 一次任务的真实消耗还包括推理、输出、联网、工具结果、图片和失败重试。
Astra 的出现，直接干碎了你辛苦搭建的脚手架
OpenAI 对 Astra 的定位是面向复杂端到端工作的旗舰模型：更擅长多步骤任务、计算机操作、研究和文档生产。官方迁移指南还特别强调，它能在常规缺口上自行判断，在真正影响结果的地方才提出问题，并能在任务中途接收新指令而不丢失原目标。
这意味着旧模型时代留下的一部分“控制脚手架”，现在可能从保障变成负担。
以前，为了防止 Agent 跑偏，我们习惯把所有背景、规则、例外、检查表都塞进 AGENTS.md 和 Skill；每一步都要求汇报，每遇到模糊处都暂停确认。模型能力有限时，这些护栏确实有用。但当模型的判断力和任务连续性提升后，继续叠加同样密度的控制层，会产生三个副作用：
- 真正与当前任务有关的信息，被埋在大量常驻规则里；
- 多个 Skill 对同一动作发出相近但不完全一致的指令；
- Agent 把精力花在遵守流程、解释流程和等待确认上，而不是完成任务。
所以，升级 Astra 不是简单地把模型名替换成 gpt-6-astra。模型换代后，控制层也应该重新审计。
优化前，先梳理清楚 Astra 消耗的 4 笔账单
第一笔账：每轮都加载的常驻指令
先看根目录的 AGENTS.md、全局规则和系统 Prompt。
它们最适合放三类内容：项目边界、危险动作、文档路由。至于数据库细节、部署手册、写作风格全集、每个平台的格式要求，不应该每个任务都读。
我原来的问题正是把“可能有用”当成“必须常驻”。写一篇小红书文案，也要带上架构、记忆、发布、复盘和多平台规则。单份文件看起来都不大，串在典型路径里就非常可观。
一个更轻的根文件应该像路由器：
# AGENTS.md
- 修改代码前读取 docs/engineering.md
- 涉及数据库时读取 docs/database.md
- 涉及对外发布时读取 docs/publishing.md
- 仅在删除、付款、公开发布等高风险动作前确认
- 完成定义：实现、检查、修复、复测并报告结果
根文件负责告诉 Agent “什么时候去哪里找”，不负责把整个知识库复制进上下文。
第二笔账：被错误触发的 Skill
Skill 不是越多越强。它至少要回答三个问题：
- 什么时候触发？
- 触发后完成什么结果？
- 什么情况下停止或移交？
如果 Skill 的描述过宽，例如“任何内容任务都使用”，选题、调研、写作、润色和发布就可能同时命中。此时 Agent 不只要读取更多文件，还要处理规则之间的优先级冲突。
我的调整是把根 Skill 缩成路由层，把详细模板和平台规范放到 references/：只有写小红书时才读小红书规范，只有进入发布环节时才读发布检查表。这就是渐进式读取。它减少的不是知识，而是无关知识进入当前任务的概率。
第三笔账：工具输出与轮询
很多人只统计 Prompt，却忽略工具结果同样会占上下文。
最典型的浪费包括：全仓扫描后返回几千行文件、反复读取没有变化的日志、子 Agent 每几十秒回传一次“仍在运行”、为了找一条规则把整份历史会话塞回来。
优化方法很朴素：
- 先列候选文件，再读少数相关文件；
- 日志按日期、关键词和行数截取；
- 等待任务只在状态变化、失败或需要人工决定时回传；
- 工具输出先提取结论和证据路径，不把原始噪声永久带下去。
这部分不一定体现在 AGENTS.md 的 KB 数，却经常是长任务越跑越慢的真正原因。
第四笔账：所有任务都调用最贵模型
Astra 更强，不代表每个动作都应该用 Astra。
复杂研究、跨应用执行、重要判断和最终验收，适合交给高能力模型；文件检索、格式转换、批量改名和固定模板填充，则可以交给更便宜、更快的执行模型。
这里的关键不是机械地“主模型 + 一堆子 Agent”，而是按任务难度路由。子 Agent 每启动一次，也可能重新加载项目规则、工具说明和上下文。一个本来十分钟能完成的任务，被拆成五个角色后，未必更便宜，只是看起来更像组织架构。
我第一次优化失败了：规则少了，文章也空了
这次改造里最有价值的发现，不是 79.2%，而是一次真实的失败。
第一版优化时，我把内容系统里大量步骤砍掉，写作链路确实更短了。但随后用它重写 Astra 选题，Agent 直接根据已有材料开写，跳过了自媒体平台热度、用户痛点和真实讨论的调研。
文章很顺、结构也完整，就是隔靴搔痒。它像一篇“正确的官方摘要”，不像一个真的遇到额度问题、拆过系统、踩过坑的人写的内容。
这说明优化 Agent 规则不能只看字节数。应该删除的是重复说明、常驻背景和过度确认，不能删除的是决定内容质量的条件门：
- 事实会变化时，必须联网核验；
- 内容依赖用户情绪和平台语境时，必须做真实信号调研；
- 涉及安全、付款、删除和公开发布时，必须保留确认；
- 任务交付前，必须按验收标准复测。
好的控制层不是规则最少，而是该出现的规则只在正确时刻出现。
一套可以复现的 Agent 配置审计
如果你也怀疑自己的 Agent“规则太重”，可以按下面的顺序检查。
1. 先备份，再建立清单
不要一上来删除文件。先备份 AGENTS.md、Skill、任务 Prompt 和它们引用的文档，然后记录：
- 文件数量与总字节数；
must、必须、never、不得等强约束数量；- 一次典型任务实际会读取哪些文件；
- 哪些规则内容重复，哪些规则互相冲突。
2. 画出一条真实任务路径
不要拿全项目总量代替真实负载。选一个高频任务，例如“调研一个 AI 热点并写成小红书图文”，从入口开始记录它依次读取的文件和工具结果。
总资产 100 KB，并不代表每次都消耗 100 KB；反过来，如果一条高频路径每次重复读 70 KB，那么问题已经很明确。
3. 把常驻层压成路由层
逐条问：这条规则是否对 80% 以上的任务都必要？如果不是，就移到条件文档或对应 Skill 中。
可以删除重复表达，但不要为了数字好看合并不同风险等级的规则。风格建议、质量门槛和安全红线不是一回事。
4. 重写 Skill 的触发边界
把“适用于内容创作”改成更可判断的条件，例如：
当用户要求根据实时热点、平台反馈或竞品内容形成新观点时使用。
先收集信号并记录来源；没有足够证据时停止下结论，转为提出待验证假设。
短不是目的，可选择、可执行、会停止才是。
5. 收紧确认点，补全完工定义
常规、可逆、范围明确的动作，让 Agent 直接完成。确认点留给高风险或会显著改变结果的选择。
与此同时，把“完成”写清楚。例如：
完成 = 修改 + 静态检查 + 场景测试 + 修复发现的问题 + 再次验证 + 汇报证据。
否则模型可能把“给出第一版”误认为任务终点。
6. 用行为回归测试，而不只看 Token
优化后至少重跑四类场景：普通写作、需要实时调研的写作、高风险发布、长任务中途追加要求。检查它是否：
- 能正确选择 Skill；
- 不会无故停下来确认；
- 仍会在必要时调研；
- 不会绕过发布确认；
- 能完成检查、修复和复测闭环。
如果 Token 少了，但关键行为退化了，这次优化就是失败的。
我把这套方法封装成了一个 Skill
为了避免每个人手动数文件、找冲突、做备份，我把审计流程封装成了一个可直接交给 Codex 的 Skill。它会执行四件事：审计、备份、优化和验证；默认不上传隐私文件，也不会用“删得最多”冒充“优化得最好”。
项目地址：agent-config-optimizer-skill
把下面这句话直接复制给 Codex：
请从 https://github.com/markwaveio/agent-config-optimizer-skill 安装 Skill，并使用 $agent-config-optimizer 审计、备份、优化和验证当前项目的 Agent 配置。
最后：模型升级，最该重做的是控制层
Astra 的大上下文并不意味着上下文可以随便浪费；模型判断力更强，也不意味着安全门和质量门可以全部删除。
真正有效的升级是：让根规则变成路由，让知识按需进入，让低风险动作继续执行，让高风险动作停下来，让“完成”有可验证的定义。
我的系统最终减少了 79.2% 的指令资产、84.8% 的强约束和 76.0% 的典型路径静态指令 Token。但比这些数字更重要的是，我重新加回了那道一度被误删的调研门。
因为一个 Agent 系统最昂贵的浪费，从来不只是多花几千 Token。
而是它用更少的 Token，更快地写出一篇没有真实洞察的文章。
参考资料：
本文由 AI 协助整理，数据来自本人内容创作系统的实际配置审计与前后对比；观点、统计口径和最终内容由本人确认。