前言
今天台风登陆了，外面风刮得好大，明天周一还能上班吗……
这篇文章紧接上一篇文章挖的坑，详细说一下 Agentic Engineering，以及它在 Codex 中的具体实现。
Agentic Engineering 是什么
上一篇文章对 Agentic Engineering 的说明十分简略，看起来就好像用了 Agentic Engineering 以后，我只需要提出需求，其他什么都不用管了。
其实不是的！Agentic Engineering 强不强大，取决于 Context Engineering 和 Prompt Engineering 做得好不好！
这不难理解。你作为一个项目经理，总不可能只说一句需求吧？
比如，你说要赚钱，结果手下却跑去刑法里找赚钱门道了怎么办？肯定还是要先告诉他们遵纪守法，对吧？
所以，我这里给出一个自认为比较合适的 Agentic Engineering 定义：
Agentic Engineering 是一种软件开发范式，人类负责定义目标、约束条件与质量标准，AI Agent 在结构化的人类监督下，自主完成规划、编码、测试和持续演进。
为什么提出 Agentic Engineering
2026 年 2 月，提出 Vibe Coding 概念的 Andrej Karpathy 亲自按下了升级键，正式宣判 Vibe Coding 已经过时。他提出了一个全新的概念——Agentic Engineering，即智能体工程。
他为什么这么做？不难想到，肯定是 Vibe Coding 的大量使用产生了麻烦。它似乎并没有想象中那么能提高生产力。
Vibe Coding 的问题在于：对于大型项目，这种靠感觉写代码的方法走不远。长期使用，只会让项目充满屎山和漏洞。最后，AI 生成代码省下来的时间，可能又全部花在后期的审核和维护上。
于是 Andrej Karpathy 提出了 Agentic Engineering 这个概念，寄希望于它能解决 Vibe Coding 带来的问题。
怎么实现 Agentic Engineering
本小节讲解怎么具体地实现 Agentic Engineering。
因为我日常使用 Codex，所以下文都会基于 Codex 进行说明。不过，这里主要介绍工作流程和设计思路。至于怎样在 Codex 中创建、配置和调用 Subagent，我会在后续文章中单独介绍。
Agentic Engineering 的基本流程
Agentic Engineering 并不是直接把一句需求丢给 Agent，而是先让 Agent 理解项目，再让它自主完成任务。一个简化后的流程如下：
准备项目上下文
↓
提出当前需求
↓
主 Agent 分析并拆分任务
↓
主 Agent 自己执行，或按需调用 Subagent
↓
审查、测试并汇总结果
↓
用户验收
需要准备哪些上下文
其中，最重要的前置工作就是准备上下文，也就是写 AGENTS.md 之类的文件。
Agent 不知道项目原本是怎么设计的，也不知道哪些规则不能违反。如果只说一句“增加商品收藏功能”，它就只能自己猜测技术方案、目录结构和业务规则。
对于一个长期维护的项目，至少应该让 Agent 知道下面这些内容：
| 上下文 | 需要说明什么 | 电商项目示例 | 博客项目示例 |
|---|---|---|---|
| 项目目标 | 项目是做什么的，主要面向谁 | 一个前后端分离的网上商城 | 一个使用 Hugo 搭建的个人博客 |
| 项目结构 | 重要目录、文件和内容分别放在哪里 | 后端位于 backend/，前端位于 frontend/ |
中文文章位于 content/cn/，英文文章位于 content/en/ |
| 技术或工具约束 | 应该使用什么，不应该使用什么 | 使用 MyBatis，不使用 JPA | 使用 Hugo Front Matter 和标准 Markdown |
| 已有规范 | 命名、代码风格、文本风格和现有模式 | 接口统一返回 Result<T>，DTO 使用 XxxRequest 命名 |
保留作者原本的口语化表达，不随意改成正式论文风格 |
| 业务规则 | 仅靠代码不一定能推断出的要求 | 用户必须登录后才能收藏商品 | 翻译时保留专有名词、链接和代码块，不擅自改动事实 |
| 安全边界 | 哪些内容不能修改，哪些操作必须先确认 | 不得修改生产环境配置，不得提交密钥 | 不得删除原文观点，不得伪造来源和引用 |
| 决策与确认边界 | 哪些事情 Agent 可以自行决定，哪些必须先向用户确认 | 普通代码修正可以自行处理，修改数据库结构和核心接口必须先确认 | 错别字和 Markdown 错误可以直接修正，改变核心观点或大幅调整文章结构必须先确认 |
| 工作流程 | 收到任务后应该按照什么顺序工作 | 先确认接口，再实现前后端，最后审查和测试 | 先收集资料，再写作，之后审核，最后翻译 |
| Agent / 角色分工 | Main Agent 和不同 Subagent 分别负责什么 | Main Agent 负责拆分和整合，explorer 分析代码，worker 实现功能，reviewer 审查 | Main Agent 负责协调，source_researcher 收集资料，content_editor 完善正文，style_reviewer/markdown_reviewer 审核，i18n_translator 翻译 |
| 完成标准 | 怎样才算真正完成 | 后端测试通过，前端构建成功，接口和文档一致 | Front Matter 正确，Markdown 无明显错误，链接有效，中英文内容一致 |
模板见附录部分的 AGENTS.md 模板
这些长期不变的内容，可以整理到项目级说明文件中，例如 Codex 使用的 AGENTS.md。
以后再提出新需求时，就不需要重新解释整个项目，只需要补充本次任务特有的目标、限制和验收标准。
例如，在已经配置好项目上下文的前提下，本次 Prompt 可以只写：
增加商品收藏功能。用户登录后可以收藏和取消收藏商品，并在个人中心分页查看收藏列表。请复用项目现有的登录校验和分页方式，不要修改商品表；完成后运行相关测试，并说明数据库、接口和前端分别修改了什么。
所以，所谓“只需要给需求”，省略的是每次都要重复说明的项目背景，而不是省略上下文本身。
项目长期使用后，也应该根据 Agent 暴露出来的问题，继续补充规则、调整分工和完善验收标准。
为 Agent 提供工具
除了上下文以外，Agent 还需要具备完成任务所需的工具，例如读取文件、搜索资料、修改内容、运行测试和执行构建命令。
对于 Ubuntu 等系统而言，一般类似的工具都是系统自带的。
对于一些内部工具，或者 Hugo 等特殊用途工具，自行下载并添加对应的路径。
使用 Subagent 处理复杂任务
这里不会详细介绍相关技术的具体用法，只说明它们为什么会用在 Agentic Engineering 中，以及彼此如何配合。
为什么需要 Subagent
Agentic Engineering 为什么需要 Subagent？
原因主要在于 Agentic Engineering 需要收集大量上下文信息，以及将一个需求拆分为多个子任务。
比如一个前后端分离项目，一个主 Agent 当然也能完成拆分，并依次处理后端、前端、测试和文档，但所有资料、中间过程和结果，仍然会堆积在同一个上下文中。
任务简单还好，如果任务复杂，随着任务变大，单个上下文会越来越拥挤。Agent 更容易遗漏前面的约束，或者被大量代码、日志和文档分散注意力。
所以我认为 上下文隔离是 Agentic Engineering 使用 Subagent 的主要原因。 不同的子任务在独立上下文中完成，最后只把结果交回主 Agent。
除此以外，还有许多其它的优势与劣势，总结如下：
| 项目 | 单 Agent | 主 Agent + 多个 Subagent |
|---|---|---|
| 执行方式 | 以串行为主 | 独立任务可以并行 |
| 上下文 | 所有资料和过程集中在一个上下文中 | 每个 Subagent 只关注自己的任务，主 Agent 主要保留计划和结果 |
| 专业分工 | 一个 Agent 同时承担多个角色 | 可以为不同角色配置不同规则和工具 |
| 审核方式 | 容易变成“自己写、自己审” | 可以由独立的审核 Agent 重新检查 |
| Token 消耗 | 通常更少 | 通常更多 |
| 协调成本 | 较低 | 需要处理任务交接、依赖关系和结果汇总 |
| 适用任务 | 简单修改、单一领域、小规模任务 | 多模块、可并行、上下文较大或需要独立审核的任务 |
| 角色与会话 | 主 Agent 持续负责整个任务 | Subagent 的角色配置可以长期保留，但每次被调用的任务会话通常是临时的 |
怎样设计 Subagent
为了让 Subagent 真正服务于 Agentic Engineering，重点不是创建多少个 Agent，而是把每个 Agent 的职责划分清楚。
一个 Subagent 可以从说明下面这些内容入手。
| 配置内容 | 需要回答的问题 |
|---|---|
| 角色 | 这个 Agent 是谁，主要负责什么 |
| 职责范围 | 哪些任务应该交给它，哪些任务不属于它 |
| 需要读取的上下文 | 它应该优先查看哪些目录、文档、规范或资料 |
| 工具与权限 | 它可以使用哪些工具，能否修改文件、运行命令或访问网络 |
| 输入 | 主 Agent 需要向它提供哪些信息 |
| 输出 | 完成后必须向主 Agent 返回什么 |
| 完成标准 | 怎样判断任务已经完成 |
| 禁止事项 | 哪些文件不能改，哪些决策不能自行做出 |
比如为了管理博客，可以把一个 Subagent 的角色说明抽象成下面这样：
# 角色
你是博客资料收集 Agent，负责为文章查找和整理可靠资料。
## 职责
- 根据文章主题查找一手资料和官方文档。
- 记录来源、发布日期、关键结论和可用于正文的事实。
- 标出不同来源之间存在争议或无法确认的内容。
## 不负责
- 不直接重写整篇文章。
- 不为了迎合文章观点而忽略相反证据。
- 不虚构引用、链接和事实。
## 输出
- 按主题整理的资料摘要。
- 每条重要结论对应的来源。
- 需要作者进一步确认的问题。
至于这些角色在 Codex 中具体怎样创建、配置成什么文件，以及如何设置模型、工具和权限，不是本篇文章的重点，后续会单独说明。
主 Agent 怎么把任务交给 Subagent
主 Agent 相当于项目经理。收到需求后，它会先读取项目上下文，分析任务涉及哪些部分，再决定由自己完成，还是调用对应的 Subagent。
用户提出需求
↓
主 Agent 分析目标、限制和影响范围
↓
拆分子任务并判断依赖关系
↓
只调用本次需要的 Subagent
↓
收集结果，安排后续任务或返工
↓
统一审查、验证并向用户汇报
主 Agent 不会每次都调用所有 Subagent。例如，只修改一句文案时，主 Agent 可以直接完成；只修改前端样式时，可能只调用前端 Agent；只有新增完整功能时，才可能同时用到后端、前端、审核和测试 Agent。
如果任务之间存在依赖，也不能直接全部并行。例如，前端依赖后端接口时，可以先让后端 Agent 确定接口契约，再把接口路径、参数和返回结构交给前端 Agent。
简单来说，主 Agent 负责决定：任务应该拆成什么、交给谁、按什么顺序完成，以及最终结果是否满足要求。
例一：电商项目的 Agent 团队
之前推荐的博客中，作者介绍了自己的 SpringMall 项目。这个项目为 Claude Code 配置了后端开发、前端开发、代码审核、测试验证、部署和文档等多个 Agent，让不同 Agent 分别处理自己擅长的任务。
虽然原项目使用的是 Claude Code，但这种多 Agent 分工和协作的思路，同样可以应用到 Codex 中。
| Agent | 主要职责 |
|---|---|
backend-dev |
后端接口、数据库和业务逻辑 |
frontend-dev |
页面、组件和接口调用 |
code-reviewer |
检查代码质量、安全问题和规范一致性 |
test-validator |
运行测试和构建，验证功能 |
doc-writer |
更新接口文档和项目说明 |
devops-deploy |
处理部署脚本和环境配置 |
假设用户提出需求：
增加商品收藏功能。用户登录后可以收藏和取消收藏商品，并在个人中心查看收藏列表。
主 Agent 可以先分析这个需求涉及哪些模块，再根据依赖关系安排不同 Agent 执行：
用户需求
│
▼
主 Agent
理解需求 / 分解任务 / 判断所需角色
│
▼
backend-dev
实现数据结构、接口和业务逻辑
│
▼
frontend-dev
根据接口完成收藏按钮和收藏列表
│
▼
doc-writer
更新相关接口文档和项目说明
│
▼
code-reviewer
审查前后端改动
│
▼
对应开发 Agent
根据审核意见修复问题
│
▼
test-validator
运行测试和构建 / 验证功能
│
▼
主 Agent
汇总结果 / 检查任务完成情况
│
▼
交给用户验收
这里没有调用 devops-deploy，因为当前需求并不涉及部署。
同样，主 Agent 也不会为了使用 Agent 而调用所有角色，而是根据实际任务动态选择。例如，如果只是修改收藏按钮的样式，可能只需要调用 frontend-dev；如果只是补充接口文档，则可能只需要调用 doc-writer。
也就是说，Agent 团队更像是一组可以按需调用的专业角色，而不是每次任务都必须完整执行一遍的固定流水线。
例二：使用 Agent 团队管理博客
Agentic Engineering 不一定只能用于写代码。只要一个任务能够拆分成不同职责，并且这些职责之间存在明确的输入、输出和协作关系，就可以使用类似的 Agent 工作流。
例如，可以为个人博客设计下面几个 Agent：
| Agent | 主要职责 |
|---|---|
Main Agent |
理解需求、维护作者上下文、规划任务、综合资料、正文写作与最终修改 |
source-researcher |
搜索资料、提取证据、保留原始来源、标注局限 |
idea-explorer |
发散观点、问题和角度，不替作者决定最终观点 |
fact-checker |
核对事实、引用、推论和资料使用 |
style-reviewer |
检查是否符合博客原有语气和风格，只提出修改建议 |
markdown-reviewer |
检查 Hugo、Markdown、Front Matter 等格式规范 |
i18n-translator |
在中文定稿后生成英文版 |
section-writer |
可选角色，只用于独立章节、候选版本或上下文相对自包含的写作任务 |
主 Agent 相当于博客的主编和主笔。
它不仅负责接受需求和调度其他 Agent，还负责维护完整的作者上下文，包括文章原本想表达什么、作者已经写了什么、资料应该如何使用，以及最终哪些内容应该保留、修改或删除。
假设用户提出需求：
完善一篇介绍 Agentic Engineering 的博客。保留我现在的语气和观点，补充可靠资料，检查 Markdown 格式，并在中文版确认后生成英文版。
主 Agent 可以这样安排：
用户需求
│
▼
主 Agent
理解需求 / 读取规范 / 分解任务
│
▼
source-researcher
收集资料 / 提取证据 / 保留来源
│
▼
主 Agent
筛选资料 / 确定结构和写作方向
│
├──► section-writer A ──┐
├──► section-writer B ──┼──► 返回局部草稿
└──► section-writer C ──┘
│
▼
主 Agent
整合 / 衔接 / 重写 / 完善正文
│
▼
审核 Agents
fact-checker
style-reviewer
markdown-reviewer
│
▼
主 Agent
汇总审核结果 / 修改定稿
│
▼
用户确认中文版
│
▼
i18n-translator
生成英文版
│
▼
最终审核
检查格式 / 术语 / 中英文一致性
│
▼
主 Agent
最终检查 / 交付文章
其中，section-writer 并不是默认负责整篇文章，而是一个可以按需调用的并行写手。
当文章包含多个相对独立的章节时，可以让多个 section-writer 同时生成不同章节的草稿。例如技术教程、资料型长文，或者由多个独立主题组成的文章，都比较适合这种方式。
这些 Agent 生成的内容仍然只是局部草稿。最终需要由主 Agent 统一整合、删减、衔接和重写，避免不同章节之间出现内容重复、观点冲突、术语不统一或者明显的多人写作痕迹。
如果文章本身具有很强的连续性，例如随笔、个人经历、观点形成过程或者情绪变化，则通常不适合拆给多个写作 Agent。
这类文章的重点往往不是单独某一章写得是否完整，而是作者的思路如何一步步发展：
经历或灵感
↓
产生疑问
↓
查找资料
↓
形成新的理解
↓
得到自己的观点
↓
完成表达
如果把这个过程拆给多个 Agent，容易因为反复传递和压缩上下文，使作者原本连续的思路、语气和表达方式被削弱。
因此，这类文章通常更适合由主 Agent 直接负责正文写作，只把资料搜索、事实核查和风格检查等相对独立的任务交给 Subagent。
同样，主 Agent 只会调用当前任务真正需要的角色：
- 只改错别字或格式时，不需要调用资料 Agent 和写作 Agent。
- 只核查文章中的事实时，可以只调用
fact-checker。 - 文章没有适合并行拆分的章节时，不需要调用
section-writer。 - 只翻译已经完成并确认的文章时，可以直接调用
i18n-translator。 - 对随笔类文章，主 Agent 通常直接负责正文写作，只把资料搜索、事实核查和风格检查等相对独立的任务交给 Subagent。
因此，这套分工并不是一条固定的流水线，而是由主 Agent 根据文章类型和当前任务动态组合：
主 Agent
├── 探索：source-researcher / idea-explorer
├── 并行生产：section-writer
├── 审核：fact-checker / style-reviewer / markdown-reviewer
└── 转换：i18n-translator
主 Agent 始终负责：
理解上下文 → 做出取舍 → 整合内容 → 最终写作和定稿
这种分工可以减少多次上下文传递带来的信息损耗。
例如，如果采用“资料 Agent 总结一次 → 主 Agent 再转述一次 → 写作 Agent 再理解一次”的流水线，原始资料和作者意图可能会在多次转换中逐渐被压缩。
现在的分工则让主 Agent 始终掌握完整上下文，把搜索、并行处理、审核和翻译等相对独立的任务交给 Subagent，在降低信息损耗的同时，也保留了多 Agent 协作在专业分工和并行执行方面的优势。
总结
总而言之， Agentic Engineering 的出现是为了解决 Vibe Coding 的问题。
它并非用户只说需求就能完成工作了，要想正确的使用它，就需要提供足够的上下文信息。
除了代码编辑，博客管理等工作流它也可以完成。
参考资料
讲解 Agentic Engineering：
Codex 官方文档：
附录
AGENTS.md 模板
# AGENTS.md
## 1. 项目目标
* 项目是做什么的：
* 主要面向谁：
* 当前主要目标：
* 最重要的结果是什么：
## 2. 项目结构
* 重要目录：
* 重要文件：
* 各目录和文件分别负责什么：
* 新增内容应该放在哪里：
* 修改前需要优先查看哪些文件：
## 3. 技术或工具约束
* 必须使用：
* 优先使用：
* 不应使用：
* 版本或环境要求：
* 特殊工具、格式或框架要求：
## 4. 已有规范
### 命名规范
* 文件命名：
* 目录命名：
* 变量、类型、接口或文章命名：
### 结构规范
* 代码或文章应该如何组织：
* 标题、章节或模块结构：
* 已有模式应如何保持：
### 风格规范
* 代码风格：
* 文本或写作风格：
* 排版和格式要求：
* 不应擅自改变的风格：
## 5. 业务规则
* 仅靠代码、文件或目录无法直接推断出的业务规则：
* 特殊状态、流程或权限规则：
* 数据之间的关系：
* 多语言、同步或兼容规则：
* 其他必须知道的项目约定：
## 6. 安全边界
### 不得修改
*
*
### 不得删除
*
*
### 不得虚构或猜测
*
*
### 高风险操作
以下操作必须谨慎处理：
*
*
### 敏感信息
* 不得提交：
* 不得输出：
* 不得记录：
## 7. 决策与确认边界
### Agent 可以自行决定
* 明显错误的修正。
* 不影响原意和行为的小范围调整。
* 符合现有规范的常规实现。
*
### 必须先确认
以下情况不得擅自决定：
* 改变核心需求、观点或业务逻辑。
* 大规模删除或重构。
* 修改重要数据结构、接口或公共约定。
* 存在多个合理方案且影响明显。
* 资料、事实或需求存在冲突。
*
*
### 不确定时
* 不要猜测。
* 优先检查已有项目内容和规则。
* 仍无法确认时，明确指出不确定点。
## 8. 工作流程
收到任务后，一般按照以下顺序工作：
1. 理解用户目标和当前任务。
2. 阅读相关文件和当前适用的 `AGENTS.md`。
3. 检查已有实现、内容和规范。
4. 判断是否需要外部资料或专业 Agent。
5. 制定最小必要的修改方案。
6. 完成主要实现或修改。
7. 进行审查、测试或格式检查。
8. 修复发现的问题。
9. 确认完成标准。
10. 汇总修改结果和仍需用户决定的问题。
根据任务性质，可以省略不必要的步骤，但不得跳过关键验证。
## 9. Agent / 角色分工
### Main Agent
负责：
* 理解用户最终目标。
* 拆分任务。
* 判断是否需要调用 Subagent。
* 协调不同 Agent 的执行顺序。
* 汇总不同 Agent 的结果。
* 处理不同 Agent 之间的冲突。
* 对最终结果负责。
### `<agent_name>`
负责：
*
*
不负责：
*
*
### `<agent_name>`
负责：
*
*
不负责：
*
*
### 协作原则
* 不要求每次任务都调用所有 Agent。
* 只在职责匹配时调用对应 Agent。
* 不同 Agent 的职责尽量避免重叠。
* Agent 返回结果后，由 Main Agent 负责整合。
* Subagent 必须遵守当前项目适用的 `AGENTS.md`。
* 如 Subagent 的一般规则与本文件明确规则冲突，以本文件为准。
## 10. 完成标准
任务只有满足相关条件后才算完成。
### 内容或实现
* 需求已经完成。
* 没有明显遗漏。
* 没有无关修改。
* 没有破坏已有行为或内容。
### 规范
* 符合项目结构和命名规范。
* 符合代码、文本或排版规范。
* 符合业务规则和安全边界。
### 验证
* 必要测试已经执行。
* 必要构建、检查或审查已经完成。
* 已处理明显错误和警告。
* 外部链接、引用或依赖在需要时已经确认。
### 一致性
* 代码、文档、接口或多语言内容保持一致。
* 修改没有造成明显冲突。
* 已同步需要同步的相关内容。
### 最终确认
* 无法确认的信息已经明确指出。
* 需要用户决定的问题已经列出。
* 不为了追求“更完善”而无限继续扩展任务。
## 通用原则
* 本文件是项目规则的主要来源。
* 修改项目规则时，优先更新本文件。
* Subagent 配置应根据本文件同步维护。
* 修改前先理解现有内容，不要脱离上下文重新设计。
* 优先进行最小必要修改。
* 保持已有项目风格和模式。
* 不确定的信息不要猜测。
* 不要为了优化而擅自改变用户明确表达的需求、观点或意图。
* 当任务已经满足完成标准时，应停止继续扩展。
文章作者：成元
上次更新：2026-07-20