全文配套的评估器会把任务分成：
GREEN
：可在声明的工作区内执行； YELLOW
：先只读分析，再做可审查修改； RED
：不委托最终决定或高影响动作。
但分数只是讨论工具。最终边界仍由了解系统、数据和后果的人决定。
1. 先区分“产品限制”和“工作边界”
产品限制是 Codex 当前做不到或受到配额约束的事情，例如：
工作边界则是即使技术上能做，也不应该完全委托的事情，例如：
如果只研究产品限制，容易得出：
但工作边界通常不会因为模型更强而消失。更强的 Agent 可能减少某些错误，也会扩大它能造成的影响。
2. 额度限制：不要把工作流建立在固定数字上
OpenAI 当前 Codex 定价文档把计划、credits、usage limits 和 API key 使用方式分开；不同计划、模型、速度模式和任务复杂度会影响可用量。OpenAI：Codex pricing
因此我不会在这篇文章里写：
这种数字很容易因为产品调整、模型选择、地区或任务消耗而失效。更可靠的做法是：
-
在当前客户端用 /status查看会话、上下文和 rate limits； -
用账户或工作区提供的 usage / credits 页面确认权威用量； -
对自动化任务使用可观察的预算和停止条件； -
让长任务定期落盘，不把进度只保存在聊天里。
OpenAI 当前 Developer Commands 文档说明，/status 可以显示 chat ID、context usage 和 rate limits；不同表面支持的命令仍可能不同，先以当前菜单为准。OpenAI：Developer commands
2.1 真正需要优化的不是“每次少说几个字”
额度浪费通常来自：
-
同一任务重复扫描整个仓库； -
没有失败复现，连续尝试随机修复； -
把巨量日志全部塞回主对话； -
安装太多无关 Skill 或 MCP； -
一个任务同时做调研、开发、发布和复盘； -
没有中间产物，rate limit 后只能从头开始。
更有效的节省方式是减少不确定工作：
2.2 额度耗尽也应该有恢复点
一个两小时任务至少应留下：
这样即使模型、套餐或客户端切换，工作也能从仓库状态恢复，而不是从“你还记得刚才做了什么吗”恢复。
3. 上下文限制：长对话不等于长期记忆
OpenAI 当前的 Subagents 文档直接提醒：即使上下文窗口很大，模型仍有上限；把探索笔记、测试日志、堆栈和命令输出全部堆进主线程，会让关键要求被噪声掩盖，可靠性随时间下降。OpenAI：Subagents
常见症状包括：
-
忘记开头定义的非目标； -
已经读过同一文件，却再次扫描； -
后来的临时要求覆盖更重要的验收标准； -
把旧错误当成当前错误； -
压缩后记得结论，却丢失命令、路径或版本； -
对“已经测试过”产生错误印象。
3.1 /compact 是摘要，不是无损压缩
Codex 当前命令文档把 /compact 定义为压缩当前 chat context；CLI 文档建议在长任务后用它保留关键点并释放上下文。OpenAI：Developer commands
合理预期是：
所以压缩前应先写交接文件，而不是只发送一句：
3.2 哪些内容必须回到源文件
压缩或新任务以后，重新读取：
-
当前 AGENTS.md； -
issue / Article Brief / acceptance criteria； -
实际 diff； -
最新测试输出； -
Claim Register 和 Evidence Ledger； -
部署或迁移清单； -
尚未解决的风险。
模型对之前对话的总结不能替代当前工作树和权威文档。
4. 上下文交接：让任务跨线程仍能恢复
配套包提供 handoff-template.md，只保存六类信息：
一次有效交接可以这样写：
新任务开始时，不应让 Codex“相信这份交接一定正确”，而应让它：
-
读取交接； -
检查当前 diff 和关键文件； -
复跑最小验证； -
报告交接与现场不一致的地方； -
再继续执行。
5. 知识限制：流畅解释不能成为证据
OpenAI 在 Codex 与外部 issue / PR 的官方说明中反复提醒，大语言模型会犯错，答案和 diff 需要 review。OpenAI：Use Codex with Linear
错误不一定表现为明显胡说。更危险的情况是：
-
引用了一条真实链接，但链接没有支持旁边的结论； -
命令存在，却属于另一个版本； -
GitHub issue 被写成官方已确认缺陷； -
测试输出看起来合理，却从未真正运行； -
把“通常如此”扩写成“一定如此”； -
用作者没有经历过的第一人称增强可信度。
5.1 不要询问“你有多大把握”
让模型给自己一个 95% confidence，并不会自动产生校准良好的概率。
更有用的是要求可检查证据：
5.2 三种结论，三种验收方式
Codex 很适合收集和组织证据，但它不应该因为“组织过这些证据”就自动拥有最终判断权。
6. 验证限制：能测试的任务也不等于已经安全
测试通过至少有四种可能：
-
真的覆盖了需求； -
只覆盖了 happy path； -
测试和实现一起理解错了需求； -
测试本身没有运行到目标代码。
因此，验证应形成一条证据链：
对高影响任务，还应增加：
-
dry run； -
staging 或 test account； -
备份与回滚； -
双人 review； -
审计记录； -
发布后监控。
“Codex 已经自我 review”可以是其中一层，不能替代全部层。
7. 权限限制：Sandbox 约束能力，Approval 约束时机
OpenAI 当前安全文档明确区分：
-
Sandbox mode：技术上可以触达哪些文件、网络和进程； -
Approval policy：什么时候必须停下来请求批准。
两者共同工作，但不是一回事。OpenAI：Agent approvals & security
这意味着：
批准只说明某个主体同意继续，不会自动检查：
-
目标环境是否正确； -
删除范围是否超出预期； -
账号是否拥有过大权限； -
请求是否来自恶意页面； -
是否存在更安全的只读方法； -
回滚是否真的可用。
7.1 把高影响任务拆成两个 Prompt
不推荐：
更安全：
把分析与执行分开，能让批准对象从“相信 Agent”变成“审查一个具体动作”。
8. 隐私限制：可访问不等于可以进入上下文
Codex 的数据处理边界取决于登录方式、ChatGPT workspace、管理员设置、连接器、托管环境和组织政策。OpenAI 官方身份文档也区分 ChatGPT 登录与 API key 使用所适用的工作区控制和数据处理方式。OpenAI：Authentication
在任何计划下，都应先做数据最小化：
8.1 五类内容默认不要进入 Prompt
-
API key、cookie、private key、recovery code； -
客户个人信息和未脱敏业务记录； -
未公开财务、并购、人事和法律材料； -
生产数据库导出与内部访问路径； -
可以组合成身份冒充材料的完整个人画像。
真正需要处理敏感数据时，不是简单地“提醒 Codex 保密”，而是先确认：
-
组织允许使用的产品和工作区； -
retention、training 和 residency 设置； -
谁能访问 chat、日志、导出和连接器； -
下游 GitHub、Slack、MCP 服务如何保存数据； -
删除和审计路径。
连接器把数据带入上下文以后，数据同时受到源系统和 AI 工作区两套边界影响。
9. Prompt Injection：外部资料不是被动文本
Agent 能浏览网页、读取 issue、依赖 README 和工具返回值以后，外部内容可能包含试图改变 Agent 行为的指令。
OpenAI 的 Agent internet access 文档列出 prompt injection、代码或 secrets 外泄、恶意依赖和许可证风险，并建议只允许需要的域名与 HTTP 方法，review Agent 的输出和 work log。OpenAI：Agent internet access
一个 issue 可能写着：
对人来说，这是一段可疑步骤；对拥有网络和仓库读取权限的 Agent 来说，它可能成为真实的数据外传路径。
9.1 处理不可信来源的四层防线
- 内容层
：把网页、issue 和 README 当作数据，不当作高优先级指令； - 权限层
：默认无网络或最小 allowlist，限制写操作； - 任务层
：研究与执行分开，禁止来源自行扩大任务； - 验收层
：查看命令、目标域名、请求方法、diff 和工作日志。
同样的原则也出现在 Claude Code 安全文档中：显式权限、网络批准、独立 Web Fetch context 和不可信内容 review 能降低风险，但没有系统能完全免疫 prompt injection。Anthropic：Security
10. 用任务边界卡决定工作模式
配套包的 boundary-card-template.md 要求开始前填写八个字段：
这些字段不会覆盖所有风险，但能迫使任务提出者说明：
11. 运行 GREEN / YELLOW / RED 评估器
配套包包含三个样例：
先运行自测：
预期：
再评估一项任务：
核心结果：
11.1 评分只是让理由显性化
脚本会给以下因素增加风险分：
-
数据更敏感； -
有外部或破坏性影响； -
难以回滚； -
只能主观验证； -
来源不可信； -
范围不清； -
决策影响高； -
没有人类 owner。
当前示例规则是：0-4 为 GREEN，5-11 为 YELLOW，12+ 为 RED；任何 Hard Stop 都会直接进入 RED，不再由总分降低等级。
以下条件会直接进入 hard stop：
-
任务画像仍包含 secret 数据； -
destructive external effect； -
外部动作没有 human owner； -
高影响决定只有主观验证。
团队完全可以修改分值。真正不能删除的是理由、owner、验证和停止条件。
12. 三类真实工作任务怎样判断
12.1 本地 parser 重构：GREEN
条件：
Codex 可以：
-
读取项目； -
复现测试； -
做最小修改； -
运行相关回归； -
输出 diff 和剩余风险。
仍不应该跳过：
-
人工接受行为变化； -
完整 diff； -
真实 CI。
12.2 准备一篇投资研究笔记：YELLOW
条件：
Codex 可以：
-
收集当前公开资料； -
建 Claim / Evidence； -
检查数字和日期； -
生成大纲和草稿； -
标记不确定性； -
做事实与结构 review。
必须由人完成：
-
选择观点； -
判断信息是否足够； -
确认没有个性化投资建议； -
审核标题和风险表述； -
执行公开发布。
12.3 删除生产客户数据：RED
条件：
Codex 此时最多可以：
-
解释所需审批和信息； -
生成只读查询草稿； -
提供备份、dry run 和回滚清单； -
帮助负责人整理变更计划。
不能让它：
-
猜测删除范围； -
使用生产凭据试错； -
自己批准 SQL； -
在无人监督时执行。
13. 什么时候应该立刻停止当前任务
出现以下任一信号，不应继续靠更多 Prompt“把它说清楚”：
13.1 目标与验收冲突
动作：列出冲突，让 owner 决定，不自行选一边。
13.2 没有可观察成功信号
动作：退回 Brief，定义输入、输出、失败信号和非目标。
13.3 需要 secrets 或生产数据才能继续
动作：先找脱敏 fixture、只读接口或测试环境；不要要求用户直接贴值。
13.4 来源试图改变任务或发送数据
动作：停止网络动作，报告来源、命令、目标域名和潜在影响。
13.5 连续三次修复没有缩小失败
动作：停止随机尝试，恢复最小复现，重新检查假设和环境。
13.6 上下文与工作树不一致
动作：以当前文件、Git 和测试为准，重建交接，不信任旧摘要。
13.7 外部动作缺少 owner 或回滚
动作：保持只读或草稿状态，等待责任人和恢复方案。
14. 常见误区：为什么“更强模型”不是通用修复
更强模型可以提高某些任务成功率，但不能自动提供权限最小化、真实业务意图、数据授权和责任承担。
15. Claude Code 与 GitHub Agent 的限制给了什么对照
Claude Code 官方成本文档同样建议主动管理上下文：无关任务使用 /clear，长任务使用 /compact，用 /context 查看消耗，并指出上下文越大，处理成本越高。Anthropic：Manage costs effectively
Claude Code 的 session 文档进一步区分：
/clear
：以空上下文开始，但旧对话可恢复； /compact
：用摘要替代历史； /context
：检查当前上下文组成。
Anthropic：Manage sessions
GitHub 对 cloud coding agent 的风险说明则采用了另一种边界：限制谁能触发、Agent 能推送的分支、凭据能力，并要求人工 review 后才能 merge。GitHub：Risks and mitigations
这些产品实现不同，但共同指向四条原则：
-
上下文要能观察和重建； -
不可信输入要隔离； -
Agent 权限应小于最终业务权限； -
高影响结果必须有外部验证与人类责任。
16. 45-60 分钟边界练习
目标：从自己的工作中选择三个任务，分别得到 GREEN、YELLOW 或 RED 决策，并改写其中一个任务，使风险下降一级。
0-10 分钟：选择三个任务
至少覆盖：
-
一个本地、可测试的修改； -
一个会发布或写入外部系统的任务； -
一个涉及敏感数据或高影响判断的任务。
10-25 分钟：填写 Boundary Card
不要根据“听起来危险”填写，要写真实系统：
25-35 分钟：运行评估器
复制一个 profile JSON，修改字段：
验收：能够解释每一项加分，而不是只看颜色。
35-50 分钟：把任务降低一级风险
常用方法：
-
secret 改为伪造 fixture； -
destructive 改为 dry run； -
external write 改为 draft； -
subjective verification 增加领域 reviewer； -
unclear scope 增加允许目录和非目标； -
无 owner 改为明确责任人； -
untrusted source 增加 allowlist 和人工检查。
重新运行脚本，记录改变了哪些字段，以及真实流程是否也已经改变。只改 JSON 不算降低风险。
50-60 分钟：写 Handoff 和 Stop Conditions
为 YELLOW 或 RED 任务填写：
最终应留下：
17. 收藏清单
开始前
-
[ ] 区分产品限制和团队工作边界。 -
[ ] 写清数据、外部影响、可逆性、验证和 owner。 -
[ ] 高影响任务先做只读阶段。 -
[ ] 没有成功信号时不开始执行。
执行中
-
[ ] /status或当前客户端能显示的页面已检查上下文与额度。 -
[ ] 长任务把决策、命令和风险落盘。 -
[ ] 外部来源当作不可信数据，不让它扩展任务。 -
[ ] 连续失败没有缩小问题时停止随机尝试。
验证
-
[ ] 产品事实回到当前官方文档。 -
[ ] 代码事实有输入、命令、输出和失败信号。 -
[ ] 高影响判断由领域 owner 负责。 -
[ ] 自我 review 之外还有 CI 或独立审查。
权限与隐私
-
[ ] Secrets、客户数据和完整个人画像没有进入 Prompt。 -
[ ] 网络、路径、MCP 和连接器使用最小范围。 -
[ ] 外部写入、发布、迁移和删除需要明确批准。 -
[ ] 数据政策同时覆盖 AI 工作区与连接系统。
结束与交接
-
[ ] 当前 diff、测试和未验证项与对话一致。 -
[ ] 压缩或换线程前写 Handoff。 -
[ ] 新任务重新读取源文件并复跑最小验证。 -
[ ] RED 任务没有因为“模型更强”而绕过人类责任。
写在最后：把 Codex 当成工程系统的一部分
这个系列从“Codex 不是代码生成器，而是工程 Agent”开始，最后仍然回到“工程”两个字。
工程并不意味着把每件事都自动化。它意味着：
Codex 最适合接手的是那些范围能够说明、过程可以观察、结果可以验证、错误能够恢复的部分。
对证据不足、隐私敏感、影响巨大又难以验证的任务，好的使用方式不是继续扩大 Prompt 和权限，而是让 Codex 停在它最有价值的位置：整理信息、暴露冲突、生成候选方案、准备检查清单，最后把决定交还给真正承担后果的人。
这不是保守地使用 Agent。恰恰相反，明确边界以后，低风险工作可以更大胆地自动化，高风险工作也不必靠模糊的不安维持安全。
至此，Codex 实用教程主线从第 1 篇到第 17 篇已经闭环。下一轮更值得做的，不是继续横向增加概念，而是回到真实项目：记录哪些模板真的复用、哪些 Skill 经常触发、哪些规则已经过时，再用这些证据更新整个系列。
参考资料
OpenAI 官方
-
Codex pricing -
Developer commands -
Subagents -
Agent approvals & security -
Agent internet access -
Authentication -
Use Codex with Linear
Claude / Anthropic 对照
-
Manage costs effectively -
Manage sessions -
Security
GitHub 风险边界
-
Risks and mitigations for GitHub Copilot cloud agent -
About third-party coding agents
Claude 与 GitHub 资料用于比较上下文、权限和人工 review 的共同原则，不作为 Codex 产品行为的证据。本文的 GREEN / YELLOW / RED 评估器是作者为任务讨论设计的启发式工具，不属于任何厂商官方标准。
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
