从辅助编码到 Agentic Coding：团队如何真正把 AI 编程用起来

1. 什么是 AI 编程 / Agentic Coding

AI 编程已经不是“补全几行代码”这么简单。

过去说 AI coding，更多是在 IDE 里做补全、解释代码、生成函数；现在说 Agentic Coding，指的是 AI 不只生成代码，而是可以围绕一个目标持续工作：读代码库、理解规范、拆解任务、修改文件、运行命令、执行测试、汇报结果，再等待人审核。

这和传统“问答式 AI”的差别在于：

• 它操作的对象不只是文本，而是代码库、终端、测试、文档和任务流。
• 它接收的输入不只是一个 prompt，而是仓库上下文、团队规范、工具权限和执行边界。
• 它输出的不只是代码片段，而是一个可审查的过程和结果。

OpenAI 在《Introducing Codex》中把 Codex 定义为能在独立云沙箱里并行处理任务的软件工程 agent，并明确强调仓库里的 AGENTS.md 可以告诉 agent 如何导航代码库、跑测试、遵循项目规范。Anthropic 在《Claude Code overview》里则把这类工具定义得更直接：它可以读代码、改文件、跑命令、接 MCP、记忆项目信息、用自定义命令和 hooks 执行团队工作流。

一句话说，AI 编程的重点已经从“会不会写代码”变成“能不能在真实工程环境里稳定完成任务”。

2. 现在主流工具长什么样

今天的 AI 编程工具，大致可以分成 4 类。

2.1 IDE 内联补全型

典型代表是 Cursor、GitHub Copilot、Windsurf 这类 IDE 内工具。

它们的强项是：

• 快，适合日常编码、补全、局部修改
• 几乎不打断心流
• 更像“增强版编辑器”

它们的短板也很明显：

• 更适合局部任务，不擅长长链路任务
• 上下文通常围绕当前文件或当前会话
• 对“多步骤执行”支持有限

2.2 终端 Agent 型

典型代表是 Codex CLI / App、Claude Code。

这类工具的特点是：

• 直接在终端或沙箱中工作
• 能跨多个文件和目录完成任务
• 能跑命令、测代码、查日志、生成变更
• 更接近“合作开发者”而不是“补全插件”

这也是现在 Agentic Coding 最值得关注的一条路线。

2.3 多 Agent / 异步协作型

OpenAI 在《Introducing the Codex app》里把 Codex app 定义成一个“agent command center”。

这一类工具的核心不是单次生成，而是：

• 多 agent 并行
• worktree / 隔离副本
• 长任务异步运行
• review queue
• automations 定时执行

这意味着团队开始从“我和一个 AI 对话”进入“我在调度一组 agent 干活”。

2.4 企业流程接入型

真正成熟的落地，不会停留在 IDE 或终端本身，而会继续往下接：

• issue / ticket
• design
• docs
• CI
• release
• review

OpenAI 的《How OpenAI uses Codex》和 Anthropic 的 Claude Code 文档都在强调同一件事：AI 编程不是一个孤立工具，而是一个接进研发流程的执行节点。

3. 为什么“上下文工程”比模型参数更重要

如果说模型决定上限，那么上下文工程决定下限。

同一个 agent，在没有规范、没有边界、没有工具约束的仓库里，常常只能给出“像是对的”结果；一旦把团队规则、常见命令、外部依赖和重复流程固化好，它的稳定性会明显提升。

这也是为什么我更建议团队优先建设：

1. AGENTS.md
2. Skill
3. MCP

不是反过来。

3.1 AGENTS.md 是最基础的持久上下文

AGENTS.md 的价值，在于它把“每次都要重新说一遍的话”固化到仓库里。

最适合放进去的内容包括：

• 仓库结构怎么理解
• 哪些目录能改，哪些不要碰
• 跑测试和构建的标准命令
• 代码风格、提交规范、评审要求
• 哪些历史坑和业务约束不能靠读代码推断

OpenAI 在《Introducing Codex》和《How OpenAI uses Codex》里都明确强调了 AGENTS.md 的作用：它能给 agent 持续、稳定、跨任务的仓库上下文。

对团队来说，AGENTS.md 解决的是统一口径问题。

3.2 为什么我更推荐团队优先用 Skill

OpenAI 在《Introducing the Codex app》里对 skill 的定义非常清楚：skills bundle instructions, resources, and scripts。也就是说，skill 不是一句 prompt，而是一套可复用、可执行、可共享的工作单元。

我更推荐 Skill 而不是把 MCP 当默认答案，核心原因有 5 个。

1. Skill 更适合沉淀团队方法

团队真正要复用的，往往不是“连上某个系统”，而是：

• 怎么做 code review
• 怎么写 changelog
• 怎么同步接口文档
• 怎么排查线上问题
• 怎么做发布前检查

这些本质上是方法、步骤、约束和脚本，而不是“外部系统连接协议”。

Skill 正好适合承载这些内容。

2. Skill 更容易版本化和审查

Skill 可以直接放进仓库，跟代码一起评审、迭代、回滚。

这对团队非常重要，因为它意味着：

• 变更可追踪
• 规则可审查
• 经验可继承
• 新成员可复用

OpenAI 也明确写到，skills 可以在 app、CLI、IDE extension 之间复用，也可以 check in 到仓库里供团队共享。

3. Skill 的权限面通常更小

大部分 Skill 的核心是：

• 指令
• 本地资源
• 已知脚本
• 固定工作流

相比之下，MCP 经常意味着：

• 额外 server
• 远程连接
• 外部认证
• 实时数据访问
• 可执行工具调用

对团队治理来说，Skill 通常更容易做权限收敛和风险控制。

4. Skill 的复现性更强

Skill 更像“标准作业程序”。

只要输入条件差不多，输出路径通常也比较稳定。它更容易形成：

• 项目 onboarding skill
• 发布检查 skill
• API 文档同步 skill
• 故障排查 skill

这类资产的价值，远高于一次性的 prompt。

5. Skill 更适合先落地，再扩展

很多团队一上来就谈 MCP，最后会卡在：

• server 怎么部署
• 认证怎么管
• 数据怎么授权
• 哪些 tool 可以执行
• 审计怎么做
• 出问题怎么排查

而 Skill 的起步门槛低得多。先把高频流程做成 Skill，团队就已经能吃到 70% 的收益。

3.3 MCP 是什么，它有用，但不是默认答案

MCP 官方规范定义得很清楚：它是一个 host / client / server 架构、基于 JSON-RPC 的上下文与工具交换协议。它提供的核心原语包括：

• resources
• prompts
• tools
• sampling

所以，MCP 更像“协议层”和“接入层”，而不是团队方法论。

它当然有用，尤其适合这些场景：

• 读取 Figma、Google Drive、Jira、Slack、Linear 等外部系统
• 把 AI 接到实时数据源
• 暴露明确的工具调用接口
• 在多个 agent / host 之间做统一接入

但它也有天然缺点。

3.4 MCP 的几个现实问题

下面这些判断是我基于 MCP 官方规范、OpenAI / Anthropic 文档和真实团队落地经验做的归纳。

1. MCP 解决的是“连接”，不是“方法”

MCP 能告诉 agent 怎么拿资源、怎么调工具，但不会告诉团队：

• review 怎么做
• 代码规范怎么执行
• 哪些命令该跑
• 哪些步骤必须人工确认

这些还是要靠 AGENTS.md 和 Skill 来补。

2. MCP 的治理成本更高

一旦引入 MCP，你引入的就不只是一个“能力”，而是一整套额外复杂度：

• host / client / server 关系
• 能力协商
• 认证与权限
• 服务可用性
• 调用失败与重试
• 审计与追责

对于很多团队来说，这一层复杂度并不划算。

3. MCP 的安全面更大

MCP 常常连接的是外部系统和可执行工具。

这意味着你要额外考虑：

• 哪些数据能暴露给 server
• 哪些工具可以被调用
• 远程 server 是否可信
• 网络访问怎么限制
• prompt injection 后会不会放大影响面

MCP 官方规范自己也强调了 user consent、data privacy、host 侧的安全边界。换句话说，规范本身已经默认这是一个高风险面。

4. MCP 不适合承载项目内隐性规则

项目里最关键的东西，往往不是 Jira ticket、Figma 设计稿，而是那些“只有团队自己知道”的约束：

• 某个模块的历史包袱
• 某个目录不能动
• 某个字段不能改
• 某套测试必须跑
• 某类问题要先查哪几个日志

这些更适合写进 AGENTS.md 和 Skill，而不是塞进 MCP server。

3.5 一个更实用的优先级

如果目标是团队落地，我建议优先级是：

1. 先写好 AGENTS.md
2. 把高频流程做成 Skill
3. 只有在确实需要实时外部系统时，再接 MCP

也就是说：

• AGENTS.md 解决“这项目该怎么干”
• Skill 解决“这件事该怎么反复稳定地干”
• MCP 解决“这件事需要连到外部系统去干”

这个顺序更稳，也更适合团队推广。

3.6 原理：模型怎么知道什么时候用 MCP、Skill、CLAUDE.md、AGENTS.md

这部分是最容易被讲虚的地方。

很多分享会把这些东西都混在一起，说成“都是给模型喂上下文”。这不够准确。它们的原理、触发方式、控制权，其实完全不同。

先给一个最重要的判断：

3.7 MCP 的原理是什么

MCP 不是“一个插件”，而是一套协议。

官方规范把它定义成 host / client / server 架构：

• host 负责协调、授权、执行安全策略
• client 代表 host 连接某一个 server
• server 暴露 prompts、resources、tools 等能力

MCP 的基础通信是 JSON-RPC。标准 lifecycle 很明确：

1. 先 initialize
2. 做 capability negotiation
3. 再进入正常 operation

也就是说，模型不是一上来就“知道一切工具”。先是宿主把可用能力谈判清楚，后面模型和应用才在这个边界里工作。

3.8 MCP 到底是怎么触发的

这里要分 3 类看，官方规范写得很清楚：

• Prompts 是 user-controlled
• Resources 是 application-controlled
• Tools 是 model-controlled

这 3 类东西看起来都像“能力”，但触发机制完全不同。

3.8.1 MCP Prompts：用户触发

MCP prompt 更像一个可复用的模板命令。

它通常在这些时机触发：

• 用户从菜单里选
• 用户执行 slash command
• 用户显式调用某个 prompt 模板

所以 prompt 不是模型自己偷偷用的，而是用户选了，宿主再把模板展开给模型。

3.8.2 MCP Resources：应用或用户引用时触发

Resource 是上下文，不是动作。

它的典型触发方式有两类：

• 宿主自动附加
• 用户显式引用

Anthropic 的 Claude Code 文档给了很具体的例子：MCP resource 可以像文件一样用 @server:protocol://path 引用；一旦引用，资源会被自动拉取并作为 attachment 放进上下文。

所以 resource 的本质不是“让模型去执行”，而是把外部内容喂给模型看。

3.8.3 MCP Tools：模型决定是否调用

Tool 才是真正最接近“agent 在外部世界动手”的那一层。

根据 MCP 官方规范，tool 是 model-controlled。也就是：

• 宿主先把可调用工具暴露出来
• 模型在推理过程中判断是否需要用
• 真正执行前后仍然由宿主负责权限、隔离、确认和日志

所以“模型怎么触发 MCP”这句话，严格说只对 tools 部分成立；对于 prompts 和 resources，并不是同一种触发逻辑。

3.9 Skill 的原理是什么

Skill 不是外部连接协议，而是可加载的工作流包。

OpenAI 在《Introducing the Codex app》里给的定义是：skills bundle instructions, resources, and scripts。Anthropic 的 Agent Skills 文档则把原理讲得更细：Skill 是 VM / 文件系统里的目录，里面放 SKILL.md、脚本、参考资料，Claude 通过 progressive disclosure 分阶段加载。

这件事非常关键，因为它解释了为什么 Skill 更适合团队落地。

Skill 的本质不是“把外部系统接进来”，而是：

• 把团队方法包装起来
• 把说明、资源、脚本放到同一个单元
• 让模型在需要时再加载，而不是一直占上下文

3.10 Skill 是怎么触发的

3.10.1 OpenAI / Codex 的公开口径

截至 2026 年 2 月 2 日 的 OpenAI《Introducing the Codex app》，官方公开说法是：

• 你可以显式要求 Codex 使用某个 skill
• 也可以让它根据当前任务自动使用

OpenAI 公开资料目前没有像 Anthropic 那样，把内部加载分层机制写到很细。基于公开信息，比较稳妥的理解是：

• skill 至少有“可发现的描述信息”
• agent 会根据任务语义做 skill 路由
• 命中后再使用这个 skill 里的 instructions / resources / scripts

这里最后两点是基于公开行为的推断，不是 OpenAI 目前公开文档逐条写死的实现细节。

3.10.2 Anthropic / Claude 的公开口径

Anthropic 这一块公开得更细。

官方文档把 Skill 的触发写成了三层：

1. Metadata 常驻加载
   name 和 description 在启动时进入系统提示，用来做发现和匹配。
2. SKILL.md 正文 在触发时加载
   当用户请求和 skill 描述匹配时，Claude 才会去读 SKILL.md。
3. 附加资源和脚本 按需加载
   只有在正文里引用到额外文档或脚本时，Claude 才会继续读或执行。

这就是典型的 progressive disclosure。

所以，Skill 的触发不是“整个 skill 包永远都进上下文”，而是：

• 先知道“有哪些 skill”
• 再判断“当前任务像不像这个 skill”
• 命中后才读说明书
• 需要更多材料时再继续展开

这也是 Skill 比“大段系统提示”更高效的根本原因。

3.11 CLAUDE.md 是干嘛的，什么时候会用到

CLAUDE.md 不是命令，也不是插件，它是 Claude Code 的持久指令文件。

Anthropic 官方文档写得非常直接：

• CLAUDE.md 用来给 Claude 持续说明项目规则、工作流、架构信息
• Claude 在每次 session 开始时读取
• 上层目录的 CLAUDE.md 会在启动时整份加载
• 子目录里的 CLAUDE.md 会在 Claude 读到对应目录文件时按需加载

更重要的是，Anthropic 还把它和 auto memory 区分开了：

• CLAUDE.md 是你写的 instructions and rules
• auto memory 是 Claude 自己积累的 learnings and patterns

也就是说，CLAUDE.md 的原理不是“记忆库”，而是你手工维护的、可审查的、跨 session 生效的系统化说明书。

如果要问“什么时候大模型会用到 CLAUDE.md”，最准确的答案是：

• 会话启动时就用到
• 进入特定目录 / 读取特定文件时会继续加载更细粒度的规则
• 它不是等模型临时想到才去找，而是 Claude Code 的上下文装载机制本身就会处理它

Anthropic 还补了一层 .claude/rules/：

• 无路径限制的规则，启动就加载
• 带 paths 的规则，只在匹配文件被读取时触发
• 官方甚至明确写了：如果是“任务型、不是常驻型”的说明，应优先用 Skill，不要全塞进常驻 rules

这点很值得抄。

3.12 AGENTS.md 是干嘛的，什么时候会用到

先纠正一个名字。

截至 2025 年 5 月 16 日 OpenAI《Introducing Codex》和 2025 年 10 月 的《How OpenAI uses Codex》公开资料，OpenAI 官方用的名字是 AGENTS.md，不是 agent.md。

AGENTS.md 在 Codex 体系里的作用，和 CLAUDE.md 非常接近，但公开细节没有 Anthropic 那么细。

OpenAI 官方已经明确公开的点有两个：

• AGENTS.md 可以告诉 Codex 如何导航代码库、跑哪些测试、遵循哪些项目规范
• 它能给 Codex 提供 persistent context

这说明它本质上也是一种仓库级持久说明文件。

不过要注意，OpenAI 公开资料目前没有像 Anthropic 那样把“加载顺序、子目录按需加载、路径规则触发”写得那么明确。

因此，更稳妥的结论是：

• AGENTS.md 会在 Codex 处理 repo 任务时作为持续上下文被参考
• 它适合放项目规范、命令、边界、架构提示
• 它不是“外部工具触发器”，也不是“只有问到时才临时加载的知识块”

如果再往前一步说“Codex 一定在什么时候加载 AGENTS.md、一定按什么顺序合并”，那就已经超出目前公开资料了。这部分只能做实现层推断，不适合写成确定性结论。

3.13 一句话讲透这 4 种机制

如果要在分享里一句话区分它们，我建议这样讲：

• AGENTS.md / CLAUDE.md：仓库或项目的长期说明书
• Skill：按任务触发的工作流包
• MCP Resource：外部系统的可引用上下文
• MCP Tool：模型在边界内可调用的动作接口

只要把这四类分清，很多“AI 编程为什么有时候很强、有时候很笨”的现象就都能解释通。

4. 安全、沙箱、权限控制怎么做

AI 编程不能只讲效率，必须讲边界。

因为一旦 agent 能读文件、改代码、跑命令、联网，它的风险模型就已经和普通聊天机器人完全不一样了。

Anthropic 在《Making Claude Code more secure and autonomous with sandboxing》里讲得很清楚：真正关键的是两层隔离。

• 文件系统隔离
• 网络隔离

只有同时具备这两层，才谈得上“更安全地让 agent 自主执行”。

OpenAI 在《Introducing the Codex app》里也给了类似方向：默认只允许 agent 编辑工作目录内文件，默认网络受限，超出边界的命令再请求授权。

团队落地时，我建议至少做到下面几条。

4.1 默认最小权限

起步建议是：

• 默认只读
• 默认只允许当前工作目录
• 默认禁网或只允许缓存搜索
• 默认不允许高风险命令

不要一开始就给 agent 全盘读写和随意联网。

4.2 文件系统边界要清楚

最基本的限制应该包括：

• 只允许改当前 repo 或当前 worktree
• 禁止访问敏感目录
• 禁止碰 SSH key、签名密钥、全局配置
• 把产物目录、缓存目录、临时目录单独约束

4.3 网络权限要白名单化

如果 agent 要联网，建议只开放明确域名：

• 文档站
• 包仓库
• 指定 API
• 指定内部服务

不要给“任意出网”。

4.4 任何越权都必须可见

理想状态不是“绝对不出错”，而是：

• 它一旦越界就会被拦下
• 它的每一步都有日志
• 它跑过哪些命令可追踪
• 它看过哪些输出可回看

这比单纯“信任模型”更重要。

4.5 把高风险动作留给人

下面这些动作，建议默认保留人工确认：

• 推送远程分支
• 修改生产配置
• 删除大量文件
• 执行数据库变更
• 调用真实线上写接口
• 访问敏感业务数据

Agent 可以准备动作，但最后一步最好别自动做。

5. 怎么衡量效果，不只看演示

AI 编程最容易误导团队的地方，就是 demo 看起来都很强。

但真正要回答的问题不是“它能不能做出一个例子”，而是：

• 它能不能稳定处理真实任务
• 它能不能在团队环境里复现
• 它引入的返工和审查成本是多少
• 它到底是提效，还是把成本后移

5.1 外部 benchmark 能看什么

SWE-bench 是目前最值得引用的公开基准之一。

它的价值在于：

• 用的是真实 GitHub issue
• 有可复现的 Docker 评测环境
• 看的是“能不能真正解决问题并通过测试”
• 不只是比谁会生成一段像样的代码

这类 benchmark 很适合拿来解释：为什么评估 AI 编程不能只看演示视频和单次样例。

5.2 但团队不能只看 benchmark

SWE-bench 解决的是“模型 / agent 在公开任务上的能力比较”，不等于“你们团队已经能提效”。

团队真正该看的，是自己的内部指标。

5.3 更应该追踪的 8 个指标

我更建议团队跟下面这些指标：

这些指标比“生成速度很快”“看起来很聪明”有用得多。

5.4 一个简单的评估分层

我建议把 AI 编程评估分成三层：

第一层：公开 benchmark

看模型和 agent 的通用上限，比如 SWE-bench。

第二层：团队标准任务集

自己做一组固定任务，比如：

• 修一个真实 bug
• 新增一个接口字段并同步文档
• 补一组测试
• 做一次重构
• 处理一次线上告警

这层最关键。

第三层：真实研发指标

最终看：

• 交付周期有没有缩短
• 返工率有没有下降
• 线上事故有没有增加
• 文档和流程有没有更完整

只有第三层改善了，AI 编程才算真的落地。

6. 团队落地建议：先 Skill，后 MCP

如果让我给团队一个非常务实的落地顺序，我会建议这样做。

第一步：先把 AGENTS.md 写对

至少写清楚：

• 项目结构
• 核心命令
• 测试和构建方式
• 不可触碰的边界
• 提交和评审要求

第二步：把高频任务做成 Skill

最值得优先做成 Skill 的通常是：

• code review
• changelog 生成
• 发布检查
• API 文档同步
• 问题排查
• 新成员 onboarding

第三步：只把“必须连外部系统”的能力接 MCP

比如：

• Figma
• Jira / Linear
• 文档库
• 只读数据系统

不要把所有东西都往 MCP 上堆。

第四步：最后才谈自动化和多 agent

当 AGENTS.md、Skill、安全边界、评估方法都比较稳了，再上：

• automations
• multi-agent
• 长任务异步执行
• 定时巡检

这个顺序会比“先接一堆工具再慢慢补治理”靠谱得多。

7. 一个适合分享的核心结论

如果这次分享只留 4 句话，我建议讲这 4 句：

1. AI 编程已经从“补全代码”进入“Agentic Coding”，重点是能不能在真实工程环境里完成任务。
2. 团队落地的关键不是模型参数，而是上下文工程，尤其是 AGENTS.md 和 Skill。
3. MCP 很有用，但它更适合做外部系统接入，不应该替代团队方法论；默认优先级应该是 AGENTS.md > Skill > MCP。
4. 评价 AI 编程不能只看 demo，要看沙箱、安全边界、真实任务完成率和长期研发指标。

附录：核心参考材料

最值得消化的 5 份

• OpenAI《Introducing Codex》
• OpenAI PDF《How OpenAI uses Codex》
• Anthropic《Claude Code overview》
• MCP 官方规范
• SWE-bench 官方 Overview

适合补充的材料

• OpenAI《Introducing the Codex app》
• Anthropic《How Claude remembers your project》
• Anthropic《Agent Skills Overview》
• Anthropic《Making Claude Code more secure and autonomous with sandboxing》
• MCP Architecture
• MCP Server Features Overview
• OpenAI《Codex is now generally available》
• OpenAI《Introducing upgrades to Codex》

二级参考层：演讲、分享、经验材料怎么引入

这类资料很有价值，但用法要分清。

我的建议是把材料分成两层：

• 一级材料：官方文档、官方博客、官方规范
  用来定义“事实层”和“机制层”。
• 二级材料：个人演讲、经验分享、第三方解读
  用来补“讲法层”“案例层”“视角层”和“争议点”。

也就是说：

• 原理、定义、触发时机，优先引用 OpenAI / Anthropic / MCP 官方材料
• 案例、经验、选题角度、分享节奏，可以引用下面这些二手资料
• 如果二手资料里出现强事实判断，最好回到一级材料核一下再写进正文

Geoffrey Challen《A Day With Claude: Using and Teaching Coding Agents》

• 链接：Geoffrey Challen《A Day With Claude: Using and Teaching Coding Agents》
• 适合放的位置： 什么是 Agentic Coding、团队工作方式怎么变、教育和组织怎么适应
• 适合引用的点： 他这份材料像一场完整 keynote，节奏很成熟。它不是单纯讲工具，而是把“Plan -> approve -> agent 实施 -> 用测试验证”的新工作方式讲成一条完整故事线。
• 可以借鉴的内容：
  • 用“一天的工作流”讲 agentic coding，而不是一上来堆定义
  • 强调“从迭代实现，变成迭代计划”
  • 强调测试不是附属品，而是 agent loop 的 secret weapon
  • 强调组织和教育系统必须适配这种新工作方式
• 写入文档时建议： 这份更适合放在“趋势与工作方式变化”章节，作为经验案例，不要把他的个人使用数据直接当行业普遍结论。

Claude Code Anonymous《Agentic Coding: Real Talk from the Trenches》

• 链接：Claude Code Anonymous《Agentic Coding: Real Talk from the Trenches》
• 适合放的位置： 选题角度库、常见误区、经验型分享素材
• 适合引用的点： 这不是一份材料，而是一整组 presentation collection。它的价值主要不在于“给你一条权威结论”，而在于帮你找“别人都从什么角度讲 agentic coding”。
• 可以借鉴的内容：
  • 标题包装方式
  • 经验型 talk 的切口
  • 哪些话题容易引发共鸣
  • 哪些概念适合单独拆出来做一页
• 写入文档时建议： 不需要在正文里大量引用，可以单独建一个“分享选题参考池”小节，作为你们后续整理素材时的灵感来源。

Mitsuhiko《Agentic Coding: The Future of Software Development with Agents》

• 链接：Mitsuhiko《Agentic Coding: The Future of Software Development with Agents》
• 适合放的位置： 总览部分、为什么 agentic coding 突然起来了、工具全景
• 适合引用的点： 这份很适合拿来做总览视角。它对 agentic coding 的定义比较清楚，也明确讨论了工具、workflow、observability 和 context conservation。
• 可以借鉴的内容：
  • 把 agentic coding 定义成“AI 不只是建议代码，而是参与 planning / implementing / refining 的软件开发过程”
  • 强调工具和 workflow 设计原则
  • 明确提出“太多 MCP 会更快造成 context rot”，并建议对 coding agents 谨慎使用 MCP
• 写入文档时建议： 这份非常适合用来加强我们现在“Skill 优先、MCP 补充位”的论证。它不是官方规范，但它提供了很强的实战观点支撑。

hiromitsusasaki《The World Has Changed》

• 链接：hiromitsusasaki《The World Has Changed》
• 适合放的位置： 行业总览、Plan 模式 / Spec-driven development、生态变化
• 适合引用的点： 这份材料很新，也很贴近你要讲的方向。它把 spec-driven development、Plan 模式普及、Kiro / Claude Code / Copilot / Cursor 这些生态变化串在一起了。
• 可以借鉴的内容：
  • “先 plan、后 coding”正在成为主流交互模式
  • spec-driven development 可以作为 agentic coding 的上层方法论
  • 工具生态已经从单点补全进入“多工具并存 + 工作流分层”的阶段
• 写入文档时建议： 很适合放在“为什么现在突然火”和“工作方式正在怎么变”这两节，帮助把视角拉高。

Gota《CodexでもAgent Skillsを使いたい》

• 链接：Gota《CodexでもAgent Skillsを使いたい》
• 适合放的位置： Skill vs MCP、怎么把 Skill 思路迁移到 Codex、上下文工程
• 适合引用的点： 这份和我们文档现在的主线高度一致。它明确在讲：
  • MCP server 读入会吃掉不少 token
  • MCP 接太多会降低工具选择精度
  • Skill 可以做分层加载
  • 可以借助 AGENTS.md 让 Codex 识别并自主选择技能
• 可以借鉴的内容：
  • 用 L1 元数据 / L2 SKILL.md / L3 脚本 的结构讲 Skill
  • 说明为什么 coding agent 更适合 Bash / Shell + Skill，而不适合无限堆 MCP
  • 说明 AGENTS.md 可以承担“让 Codex 知道有哪些技能可选”的角色
• 写入文档时建议： 这份应该重点吸收，尤其适合补到我们现有“Skill 为什么比 MCP 更适合团队”这一节。

Sunagaku《Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし术》

• 链接：Sunagaku《Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術》
• 适合放的位置： 实战技巧、多 agent / review agent、工具对比
• 适合引用的点： 这类材料最大的价值不是给定义，而是帮你把“怎么真正用起来”讲得更接地气。
• 可以借鉴的内容：
  • 怎么讲 Codex 和 Claude Code 的差异
  • 怎么讲 subagent / review agent 这类实战玩法
  • 怎么把经验讲成“可照抄”的 workflow
• 写入文档时建议： 更适合放在后半段的“使用技巧 / 实战经验”部分，而不是前面的原理章节。

PromptLayer《Watch my AI Engineering talk: How Claude Code Works》

• 链接：PromptLayer《Watch my AI Engineering talk: How Claude Code Works》
• 适合放的位置： agent loop 原理、为什么 Bash 很重要、为什么 subagent 有效
• 适合引用的点： 这份更偏“原理拆解”。它强调的几件事非常值得吸收：
  • CLAUDE.md 本质上就是一个可编辑的 markdown 说明文件
  • Bash 是 coding agent 的 universal adapter
  • subagent 的价值在于把子任务隔离到独立上下文窗口，避免主上下文被污染
• 写入文档时建议： 很适合补在“Skill / 上下文工程 / agent loop”附近，用来解释“为什么简单工具组合反而有效”。

这些二手资料，怎么和当前文档衔接

我建议这样引入：

1. 在“什么是 Agentic Coding”里，补 Geoffrey 和 Mitsuhiko
   用来增强总览和工作方式转变的叙事。
2. 在“Skill / MCP / AGENTS.md / CLAUDE.md 原理”里，补 Gota 和 PromptLayer
   用来增强 Skill 分层加载、Bash、subagent、MCP 局限这些观点。
3. 在“为什么现在火”和“行业变化”里，补 hiromitsusasaki
   用来连接 spec-driven development、Plan 模式和生态变化。
4. 在“实战技巧”或未来的“经验篇”里，补 Sunagaku 和 Claude Code Anonymous
   用来丰富案例、标题角度和实操经验。

当前阶段的使用原则

现阶段我建议你们在正文里保持这个原则：

• 机制、定义、触发方式：优先用官方来源
• 经验、讲法、实战观点：再用这些分享材料补充
• 有争议的判断：明确标成“实践观点”而不是“协议事实”