代理、上下文、工具与模型
上一页讲了 Codex 的四种入口，但入口只是外在形式。真正决定它如何完成任务的，是四个互相配合的部分：代理、上下文、工具和模型。本篇主要参考参考/codex/02-core-concepts.md、参考/codex/11-agents-md.md和参考/codex/19-memory.md。参考材料中的核心表达可以概括为“想 → 做 → 看”，本篇把它整理成适合站点入门读者的心智模型。
先看整体关系
一次 Codex 任务大致可以抽象成下面这条链：代理（Agent）
代理是能够在多轮动作中推进任务的执行主体。参考材料使用了一个很准确的三字结构：- 想：读取相关文件、检查目录、分析报错和任务约束；
- 做：调用终端、编辑文件、运行测试或其他工具；
- 看：查看命令输出、测试结果和 diff，判断是否需要继续。
上下文（Context）
上下文是 Codex 在当前任务中可以利用的信息集合。它可能包括：- 当前请求和之前的对话；
- 工作目录、文件内容和搜索结果；
- 命令输出、测试失败信息和 Git diff；
- 项目中的
AGENTS.md指令； - 通过
@file、选中代码或其他方式明确提供的内容； - 已连接工具返回的结果。
怎样提供高质量上下文
推荐按“目标、范围、约束、验收”提供信息：@file 引用文件；如果在 CLI 中，可以明确写出路径，让代理少做猜测。
AGENTS.md 是稳定上下文
参考材料把 AGENTS.md 比作项目的“入职手册”或“交接清单”。它适合放每一轮都应遵守的确定性规则，例如：
- 项目使用什么语言、框架和包管理器；
- 测试、构建、格式化和 lint 命令；
- 目录约定和命名规则；
- 哪些目录不能修改；
- 提交前必须完成哪些检查。
工具（Tools）
工具是代理把计划变成实际动作的接口：
工具调用不等于无限授权。每个动作仍然受到当前工作目录、沙箱、审批策略和工具自身安全标记的影响。
模型（Model）
模型负责理解任务、分析上下文和决定下一步；代理负责调度动作；工具负责执行动作。三者不要混为一谈：模型强不代表它可以突破沙箱，工具多不代表每个工具都默认可用，代理会循环也不代表它能替你确认需求。 模型选择通常需要在质量、速度和成本之间取平衡：
具体模型名称和可用档位变化较快，使用时可以通过入口提供的模型选择器或
/model 查看当前可用项。
一次任务的完整循环
把四个概念合在一起，一次任务可以拆成六步：- 接收目标：理解用户想要的结果和限制；
- 加载上下文：读取项目规则、相关文件和已有改动；
- 制定下一步：决定先搜索、先运行测试还是先询问；
- 调用工具：执行读取、编辑、命令或外部工具动作；
- 检查反馈：分析输出、错误、测试和 diff；
- 继续或交付：必要时修正，完成后报告改动与验证结果。
记忆与规则的区别
参考材料特别强调了AGENTS.md 与 Memories 的区别：
“测试必须使用
pytest”应写进 AGENTS.md；“这个项目通常先启动本地服务再调试”可以作为记忆候选。密码、API key、token 等敏感信息不应写入项目规则、日志或记忆。
小结
- 代理通过“想 → 做 → 看”的循环推进任务；
- 上下文决定它当前知道什么，应该精简并明确范围；
- 工具把计划变成文件、命令和外部服务动作，但仍受权限边界约束；
- 模型负责理解和决策，不等于拥有执行权限；
AGENTS.md保存确定性的项目规则，自动记忆只作为补充；- 任务结果必须通过测试、diff 和人工判断验收。