3 posts tagged with "Codex"

很多人第一次使用 Claude Code 或 Codex 时，会把效果差异归结为“提示词写得好不好”。这当然重要，但只解释了很小一部分。

一个真正能持续工作的 AI Agent，不只是在读取一句 Prompt。它还会接收系统规则、项目规范、历史消息、代码与文档、Skill、MCP 工具描述、工具执行结果、长期记忆、子 Agent 汇总以及运行环境状态。随着任务推进，这些信息还会被检索、缓存、裁剪、压缩、持久化和重新装配。

因此，今天更准确的问题已经不是：

“我应该怎样写一句更神奇的提示词？”

而是：

“在 Agent 每一次决策前，应该让模型看到哪些信息，允许它调用哪些能力，怎样保留状态，又怎样证明任务真的完成？”

这就是从 **Prompt Engineering（提示词工程）**走向 **Context Engineering（上下文工程）**的关键变化。

本文基于截至 2026 年 9 月 4 日的 Claude 与 Codex 官方资料，建立一套不依赖具体产品界面的通用模型，并重点回答五个问题：

1. Prompt、Context、Cache、Memory、Skill、MCP 到底有什么区别？
2. Claude Code 与 Codex 如何组织项目上下文？
3. 一个 AI Agent 从接收任务到完成验证，内部经历了什么流程？
4. 多 Agent 为什么有时更强，又为什么经常更贵、更乱？
5. 怎样写一份真正适合 Agent 执行的任务提示？

AI 进入软件研发以后，最容易犯的错误，是在原有 SDLC 的“编码”节点旁边放一个聊天机器人，然后宣布团队已经完成 AI 转型。

真正的变化更深：代码生成不再是主要稀缺资源，问题选择、上下文、验证、风险判断、发布反馈和人类注意力才是。团队如果只提高生成速度，结果通常不是更快交付，而是更多 PR、更长评审队列、更高变更风险和更快积累的技术债。

因此，AI 原生 SDLC 不是“AI 帮人写代码”，而是一套新的工程操作系统：

人类定义结果、边界和风险；Agent 在隔离环境中执行；确定性系统与独立评审生成证据；发布系统控制影响面；生产反馈再写回任务、规则、测试和组织知识。

本文基于截至 2026 年 8 月 30 日可获得的一手资料，重点参考：

• Claude Code 团队的 JIT 规划、Dogfood、专家评审和扁平 Pod；
• Anthropic Security 对 Plan、Code、Test、Deploy、Monitor、Governance 的 AI 原生安全改造；
• Spotify 的 Backstage、Golden State、Fleet Management、Honk、Verifier 与 LLM Judge；
• OpenAI 的 Harness Engineering、仓库内知识、隔离环境、Agent 可观测性与任务编排；
• DORA 2025 对平台工程、交付吞吐、稳定性和信任的研究。

文章会给出完整链路、最细阶段流程、可复制模板、风险路由、工具地图、指标体系与 90 天建设计划。

2026 年 8 月 19 日，OpenAI 将 Codex 更清晰地定义为一个可供开发者构建产品的 开放 Agent Harness。这句话容易被误读成“Codex 模型开源了”，实际开放的是模型周围的运行时与集成面：会话、Agent Loop、工具执行、沙箱、审批、事件流、CLI、SDK 与 App Server。

用一句话概括：

模型决定下一步做什么，Harness 决定它能看到什么、可以怎样做、需要谁批准，以及整个过程如何被恢复和观察。

这篇文章会回答三个问题：

1. openai/codex 到底开放了什么，没开放什么；
2. 面对庞大的 Rust 工作区，应当怎样学习 Agent Harness 的原理；
3. 如何选择 codex exec、Codex SDK 或 App Server，构建自己的应用。