一、 从对话到执行：Coding Agent 诞生的必然性

2022 年末，ChatGPT 的发布让大语言模型第一次以“可对话”的形态进入大众视野，它并非首次提出大语言模型（LLM），却通过极低的使用门槛，将文本生成、问答与代码能力直接交付给普通用户，使 AI 从技术圈迅速扩散至更广泛的应用场景，由此开启了新一轮 AI 应用浪潮。

随着使用的深入，大家逐渐意识到，仅依赖对话并不足以完成复杂、长期的真实任务，围绕“目标驱动、持续执行”的 Agent 思路开始成形，一些产品（如 Manus）通过将任务拆解、工具调用和执行过程显性化，使这种范式首次以更直观的方式被用户感知，推动 AI 应用从一次性响应向持续执行演进。

在软件工程领域，这一问题尤为突出，开发者可以轻松让模型优化一段代码，但在真实工程环境中，代码往往分布在数百个文件中，伴随着复杂依赖、构建流程和测试约束，基于复制粘贴（例如：500+文件、复杂依赖）的交互方式很快失效。

正是在这一背景下，Coding Agent 成为最先在主流模型体系中落地的 Agent 形态。 以 Claude Code、OpenAI Codex 以及 Gemini 为代表的新一代模型，开始直接面向代码仓库和工程流程设计能力，使模型不再只是“写代码”，而是能够理解工程上下文、修改文件、运行测试并参与完整的软件开发过程，本文来聊聊。

说明：本文内容基于作者在实际使用与调研 Claude Code、OpenAI Codex 及 Gemini 等工具过程中的个人理解与经验总结，难免存在一定主观性，仅供技术交流与讨论参考。

二、 Coding Agent 的三大流派

围绕 Coding Agent 的实现路径，不同模型体系给出了不同的答案，以 Anthropics Claude Code、OpenAI Codex 和 Google Gemini 3 为代表，可以大致归纳出三种具有代表性的技术流派，它们在能力侧重点、工程假设以及 Agent 的工作方式上存在显著差异。

2.1 Claude Code：系统架构 师

博主深度使用过 Claude Code 一段时间，并整理了 《3万字硬核拆解 Claude Code：从入门到工程化落地（建议收藏）》 相关笔记，有兴趣的同学可以阅读，地址：https://yanglinwei.blog.csdn.net/article/details/157426627

我给 CC 的定位是 “系统架构师”，一般复杂难以解决的问题我都会找它去定位，他会帮你想清楚“该怎么做”。

CC 是一种以代码上下文理解为核心的 Coding Agent 路线，其能力重点并不在于“写出多炫的代码”，而在于稳定地理解大规模代码库的结构、语义和意图，通过长上下文窗口和对代码语义一致性的强调，Claude Code 更擅长在已有工程中进行修改、重构和增量式演进。

在使用的过程中，从终端打印的执行日志我们会发现 CC 放弃代码索引的技术，而是使用50年前的grep 搜索技术，实际上是对 “无状态” 设计哲学的现代传承，体现了 “有时候遗忘比记忆更强大” 的智慧。

2.2 OpenAI Codex：全栈工程师

博主也整理 《Codex 全面实战教程：从安装到工程协作，一篇跑通》 相关笔记，有兴趣的同学可以阅读，地址：https://yanglinwei.blog.csdn.net/article/details/157428411

如果说 Claude Code 更像一位从全局出发、先想清楚 “ 该怎么改 ” 的系统架构师，那 OpenAI Codex 更接近 “长期浸泡在真实工程里的全栈开发工程师”，关注点始终是 “下一步该做什么，怎么验证是否做对，直至完成”。

Codex 的核心技术特征并不在于复杂的代码索引或结构建模，而在于一个围绕真实工程动作展开的执行循环（Agent Loop）：模型不断在 读文件 → 改代码 → 跑命令 → 看结果 的过程中迭代前进，用执行反馈而不是静态理解来驱动决策。

关于Agent loop，可以阅读文章：https://openai.com/index/unrolling-the-codex-agent-loop

与 Claude Code 使用 grep 这类“原始但可靠”的工具、强调无状态上下文理解不同，Codex 的设计更偏向 “动作即记忆” —— 状态并不来自长期代码建模，而来自刚刚发生过的执行结果，这使它在修 bug、补测试、跑通流程等工程任务中表现得极其自然，几乎复刻了一名人类工程师在终端里的工作节奏。

从某种意义上说，Codex 并不是在试图 “完全理解代码库”，而是在通过一轮轮可验证的执行，把工程一步步推进到完成。

2.3 Google Gemini 3：前端工程师

博主整理了相关的笔记 《【万字长文】Gemini 3 Pro 全面指南：从免费订阅到 CLI / Agent 实》，有兴趣的童鞋可以阅读下：https://yanglinwei.blog.csdn.net/article/details/157432319

虽然 Gemini 3 的能力覆盖面很广，博主在一段时间的实际使用后，会比较明显地感觉到 它在前端与 UI 相关任务上的表现尤为突出，同时支持在Web端使用 Google 的 AI studio可以实时生成并预览界面。

相比偏重系统结构理解的 Claude Code，或强调执行闭环的 Codex，Gemini 3 在页面结构拆解、组件组织、样式表达以及交互逻辑推理上更为自然，往往能直接给出更贴近真实前端工程习惯的实现方式。在涉及 UI 调整、页面重构或从设计意图出发生成前端代码的场景中，Gemini 3 更关注“界面是否成立”，而不仅仅是代码能否运行，这使它在偏产品导向、体验驱动的工程任务中使用成本更低。

从 Claude Code、OpenAI Codex 到 Gemini 3，可以看到 Coding Agent 并不存在统一的实现路径，而是围绕不同的工程假设，形成了多种侧重点各异的技术路线，可以根据自己的需要去选择。

三、 opencode：把模型变成工程 Agent 的基础设施

博主在前面介绍了三种主流的 Coding Agent，它们的典型使用方式往往是在 终端（Terminal） 或 IDE 插件 里运行，但如果要体验这些工具，大家通常需要先手动安装它们，这个过程对很多人来说比较繁琐，例如这是博主在 IDEA 里安装的三个插件 ：

有读者可能会问：那为什么不用 Cursor 客户端？

确实，大家可以用 Cursor  或其它外部客户端工具，但这样不可避免需要在 开发环境和客户端之间频繁切换，而大多数开发者已经习惯把工作流程集中在自己熟悉的开发工具中：

• 后端开发更习惯用 IDEA
• 前端开发喜欢用 VS Code

因此许多人更倾向于直接在当前 IDE/终端里使用插件，而不是切换到外部应用。

还有一个问题是无论是 Claude、Codex 还是 Cursor，我们都无法完全知道它们背后的提示词、推理流程，这些都被封装在云端闭源系统里，缺乏透明度。正是在这样的背景下，opencode 的诞生并迅速走红就显得很自然了，下面来详细聊聊它。

3.1 什么是 opencode？

Github 仓库：https://github.com/anomalyco/opencode
opencode 是一个开源的 AI 编程助手 / 编码代理（coding agent），由 anomalyco 社区维护，并以 MIT 协议 完全开源发布在 GitHub 上，截止至当前，已经有 90.4K 的 Star 了，而且还在不断地上涨。

opencode 传统的 AI 编码插件不一样，它不仅仅是一个补全插件，而是一个能 理解项目上下文、分析任务、规划步骤并执行实际改动的智能工具，并支持终端（Terminal）、桌面应用、IDE 扩展等多种界面，也可以通过 API 使用。它还支持使用 超过 75+ 种大型语言模型提供商（如 OpenAI、Anthropic、Google 或本地模型）。

opencode 并不是某一个“更强的模型”，而是一套 “把模型变成工程 Agent 的基础设施”。

3.2 opencode 的优势

opencode 和传统插件/客户端 相比的一些显著优势：

• 【100% 开源、透明】：可以看到完整源码、配置和提示词设计，不会像 Copilot、Claude Code 那样是黑盒系统。
• 【多终端和 IDE 支持】：除了终端界面以外，opencode 也有桌面客户端和 IDE 扩展。
• 【支持多种 LLM 提供商】：不锁定单一厂商，你可以使用 Anthropic Claude、OpenAI GPT、Google Gemini 甚至本地模型。
• 【深度理解项目上下文】：通过集成 LSP（Language Server Protocol）等机制，opencode 能实时理解项目结构，而不是简单地基于一条提示生成代码。
• 【自定义配置和 Agents】：可以配置多个专用 agent，分别负责不同任务（如代码生成、调试或搜索），提升协作能力。
• 【客户端/服务端架构】：opencode 是一个 client/server 架构，这意味着你可以在服务器运行核心服务，然后用终端、桌面或其他客户端远程连接使用。

如果你追求 透明性、灵活性和真正与项目深度集成的 AI 编码体验，opencode 是目前生态里非常值得尝试的选择。

四、oh-my-opencode：走向多 Agent 协作的工程形态

Github 仓库：https://github.com/code-yeongyu/oh-my-opencode
oh-my-opencode 是一个基于 OpenCode 的高级插件/扩展，旨在将 OpenCode 从一个单体 Agent扩展成一个 多角色协作的智能 Agent 生态。

简单来说，oh-my-opencode 并不是另一个独立的 Coding Agent，它更像是 为 OpenCode 提供的一套 “全功能 Agent 管理和编排层”，通过预设的专用角色、工具集成与工作流，自带 “电池全装” 的 AI 开发体验。在 opencode 的基础之上，oh-my-opencode 提供：

• 【多角色智能 Agent 编排】：像 Oracle（设计与调试）、Librarian（文档和代码库探索）、Frontend Engineer（前端构建）等多个专用角色协同工作，而不是由单一 Agent 完成全部任务。
• 【后台与子任务执行】：支持后台 Agent 以及并行执行机制，让长任务和大上下文处理更高效。([Oh My OpenCode][2])
• 【深度代码智能工具集】：集成了 LSP、AST 等工具，以及自定义 MCP（Model Context Protocols），增强对项目结构、代码语义和重构操作的处理能力。([DeepWiki][3])
• 【生命周期钩子（Hooks） 与 自动化流程】：通过预设的钩子，你可以控制从分析、执行、验证到后处理等各个阶段，让 Agent 按照定义好的规则完整执行。([DeepWiki][3])

这个设计使得 oh-my-opencode 不只是 “增强版的 opencode”，而是 一个真正面向工程任务的多-Agent协作框架，让不同类型的智能角色能够互相配合，完成复杂、长流程的软件开发任务。

oh-my-opencode与 opencode 原生的区别

从这个对比可以看出，oh-my-opencode 更侧重于 工程级生产力与细粒度控制，适合大型项目和复杂任务。总的来说，oh-my-opencode 是对 OpenCode 的一次工程级扩展，让 AI Agent 的能力从 “一个助手” 进化到 “一个多角色、可编排的开发团队”。

五、 未来已来，Coding Agent 只是开始

在前面的内容中，我们主要讨论了 Coding Agent 如何走入真实的软件工程体系：从理解代码结构，到修改文件、执行命令、运行测试，逐步承担起原本由工程师完成的部分工作。但如果把视角稍微向外延伸，就会发现一个更有意思的趋势：Agent 的能力边界，正在快速溢出 Coding 领域本身。

moltbot（原名 Clawdbot） 并不是一个典型意义上的 Coding Agent，它几乎不关注大型代码库的结构建模，也不试图参与复杂的工程规划，但它所体现的，正是 同一代 Agent 思想在另一个方向上的自然延展。

与前文介绍的 Claude Code、Codex、opencode 运行在 IDE 或终端中的形态不同，moltbot 将交互入口放在了 人们最日常的工具 上：例如 Telegram、WhatsApp、Discord 等即时通讯软件。用户并不是“进入开发环境和 Agent 对话”，而是像发消息一样，向一个 长期在线的执行者下达指令。

在执行层面，moltbot 关注的也不再只是代码文件，而是更贴近真实世界的操作对象：
本地脚本、文件系统、日程、邮件以及各种可自动化的任务流程。它强调的不是“是否理解工程结构”，而是“是否能够在用户授权的环境中，把事情真正做完”。

从能力形态上看，moltbot 更接近一个 通用执行型 Agent：它同样具备目标驱动、工具调用和持续运行的特征，只是服务对象从“软件工程系统”转向了“个人数字环境”。

未来已来，而 Coding Agent 只是开始 ~

六、 一条正在展开的 Agent 演进路径

最后，博主使用 AI 生成了一张图，对全文内容做了一次整体性的抽象总结。

从 ChatGPT 的对话式智能 → 到 Manus 的任务显性化 → 再到 Claude Code / Codex / Gemini 面向真实工程的执行能力 → 继而演进出 OpenCode 这样的 Agent 基础设施、oh-my-opencode 的多 Agent 编排体系 → 直到 moltbot 这种通用执行型 Agent：

这更像是一条 按时间自然展开的技术演进路径，而非一条指向某个“终极形态”的必然路线。

任何 AI 形态的出现，本质上都源于当下工程条件、使用场景与现实需求的阶段性选择，而不是未来的唯一答案。面对层出不穷的 AI 概念与工具，与其被技术浪潮裹挟，不如保持清醒，建立自己的判断边界。

在不放弃独立思考能力的前提下，选择性地与 AI 共舞，才是我们真正可持续的进化方式 ~

1. 引言

在前面的几篇文章中，博主分别从实战与工程化视角深入讲解了当前主流的三套 Coding Agent 工具体系：Claude Code、Codex 以及 Gemini 3，感兴趣的可以先阅读：

• 《3万字硬核拆解 Claude Code：从入门到工程化落地（建议收藏）》
• 《Codex 全面实战教程：从安装到工程协作，一篇跑通》
• 《【万字长文】Gemini 3 Pro 全面指南：从免费订阅到 CLI / Agent 实战》

在实际写作和使用过程中，一个非常明显的感受是：

这三套 Coding Agent 看起来“工具不同”，但底层用的却是高度相似的一套概念体系。

例如：

• Prompt、System Prompt、Rules 到底边界在哪？
• Context、Context files、Context window 有什么区别？
• Memory、Skills、Hooks、Checkpointing 是“概念”还是“机制”？
• 为什么同一个需求，在 Claude / Codex / Gemini 里写法和落点完全不同？

这篇文章的目的，就是把这些分散在不同工具、不同命名下的概念抽象出来，放到同一张认知地图上，方便大家回顾与学习。

2. 概念详解

2.1 Prompt

Prompt （提示词）：是用户提供给 Coding Agent 的指令，用来说明要做什么事情，以及希望它怎么做，它是 Coding Agent 接收任务的主要输入，也是影响最终代码结果最关键的因素之一。

在实际使用中，Prompt 通常会包含任务背景、具体需求、约束条件（例如使用的编程语言或实现方式），以及期望的输出形式。可以把 Prompt 理解为一份“简化版需求说明”：写得越清楚，Coding Agent 对任务的理解就越准确，生成的代码也越接近预期；反之，Prompt 模糊不清，结果就容易跑偏，需要反复修改。

案例：

目标：修复当前仓库的测试失败，确保全量测试通过。
范围：仅修复导致失败的代码与必要测试；不要做无关重构。
约束：遵循现有代码风格；不要引入新依赖（除非必要并说明原因）。
验收：运行 `npm test` 全绿；输出中给出你运行过的命令与结果摘要。
信息不足：如果缺少失败日志或复现步骤，先问我 1-3 个问题。

---

2.2 System  Prompt

System prompt（系统提示词）：工具内置/预置的“默认岗位说明书/规章制度”，影响默认行为，比如是否谨慎、是否先跑测试、输出格式偏好等。

在三套工具里怎么落地（对照）：

从模型的视角来看，System prompt 并不是一种“特殊文件”或“隐藏配置”，而是在请求模型时，与用户 Prompt 一起被提交的一部分上下文，一般：

• System prompt：定义模型的长期行为、默认规则和输出契约
• User prompt：描述当前一次任务的具体需求

以 OpenAI 风格的 Chat 接口为例，一个同时包含 System prompt 和 Prompt 的请求体通常如下所示：

{
  "model": "gpt-5.2",
  "messages": [
    {
      "role": "system",
      "content": "你是一个谨慎的 Coding Agent，优先保证测试通过，避免无关重构。"
    },
    {
      "role": "user",
      "content": "修复当前仓库中失败的测试，确保 npm test 全绿。"
    }
  ]
}

2.3 Rules

Rules（规则：策略引擎/护栏）: 是一类“策略匹配 → 决策执行”的机制，当某些条件命中时，系统采取 allow / prompt / forbid 等动作（常用于高风险操作治理）。

在三套工具里怎么落地（对照）

---

2.3 Memory

Memory（记忆）：是“跨回合或跨会话能复用的信息”，为了不混淆，建议把它拆成三层来理解：

1. 短期记忆（Short-term）：当前 thread 的对话历史与工具输出（本质还是 context）。
2. 长期偏好（Long-term preferences）：比如你喜欢的输出格式、习惯（需要显式保存/配置）。
3. 项目记忆（Project memory）：项目约定、如何跑测试、目录结构等（通常落在 CLAUDE.md / GEMINI.md / AGENTS.md 或 skills 里）。

它决定了“你要不要每次都从零解释”，memory 做得好，可以显著降低 token 消耗与沟通成本。

在三套工具里怎么落地（对照）

---

2.4 Token

Token ：是模型读写的计量单位（输入 token + 输出 token），它不是严格的“字数”，更像“模型内部的编码片段”，token 直接影响：

• 成本（计费/配额）
• 延迟（上下文越大越慢）
• 可用信息量（上下文窗口限制）
• 代理稳定性（上下文过大时会压缩/丢弃细节）

在三套工具里怎么落地（对照）

常见误区：

• 误区 A：把 token 当“字符数”。
  真实情况：代码、符号、英文缩写、路径等都会影响 token 划分。
• 误区 B：以为 token 大就一定好。
  上下文越大越容易“稀释”，关键是把相关信息放进去。

小案例

同样是“修测试”，给出“失败日志 + 相关文件 + 运行命令”通常比“把整个仓库塞进去”更省 token、也更准确。

---

2.5 Checkpointing

Checkpointing（检查点/回滚点）：指“在关键节点保存一个可回退的状态”，方便：

• 撤销一次错误改动
• 回到某个已验证通过的版本继续
• 在多方案尝试中快速切换

在三套工具里怎么落地（对照）

---

2.6 Threads

Threads（线程）: 一条 thread 可以理解为“一次独立会话 + 其中的提示、模型输出、工具调用 历史”。它决定了“上下文历史在哪里、执行环境在哪里、并行怎么做”：

• 本地线程：能直接操作你的本地工作区，但需要更严格的门禁/沙箱来降低风险。
• 云端线程：在隔离环境里克隆仓库运行，适合并行委派与跨设备。

---

2.7 Context

Context（上下文）： Coding Agent 一次能 “看见” 的信息集合，例如文件内容、选中片段、命令输出、对话历史、项目说明文件等。

在三套工具里怎么落地（对照）

案例：

你问“为什么这个接口 500？”

• 好上下文：路由文件 + 控制器 + 相关中间件 + 最近报错堆栈
• 坏上下文：只给一句“接口 500 帮我修”

---

2.8 Context window

Context window（上下文窗口）：是模型一次能容纳的上下文 token 上限，不同模型不同，超过就需要：

• 摘要压缩（保留要点）
• 丢弃不相关历史
• 分批处理（分阶段/分模块）

建议：

• 长任务要“分段验收”：每段完成就总结要点，下一段继续。
• 如果工具提供 /compress、/compact、/clear 一类命令：把它理解为“整理桌面，把不需要的纸收起来”。

---

2.9 Context files

Context files（上下文文件/项目说明文件）：给代理看的“项目级说明书”，把长期有效的信息放进仓库，让代理每次都能按同一套约定工作。

三篇文章里的落地名称：

怎么写（推荐内容）

• 如何安装依赖、如何跑测试/构建（给出命令）
• 代码风格/格式化方式
• 关键目录与模块职责
• 常见坑与注意事项（例如必须先生成代码、需要特定环境变量）
• 交付要求（PR 描述模板、必须给 Test Evidence 等）

常见误区

• 误区 A：把上下文文件写成“重复 README 的大段介绍”。
  更有效：写成“可执行说明书”（命令、路径、约束、验收）。
• 误区 B：把所有背景都塞进去导致臃肿。
  更有效：把“常用但稳定”的内容放这里；把“领域知识/复杂流程”放 skills（按需加载）。

---

2.10 Compact

Compact（压缩/摘要：把上下文“整理成要点”）：指用 “摘要” 替代长对话历史或大段细节，降低上下文占用，让长任务继续跑下去。 长任务必然会遇到上下文窗口上限。压缩能延长任务续航，但也可能丢关键细节。

建议压缩前先明确“不可丢”的内容：

• 已确认的需求与范围
• 关键设计决策（为什么这么做）
• 运行/验证命令（DoD）
• 风险与回滚策略
• 压缩后立刻做一次“自检复述”：让代理用清单复述它接下来会做什么，确认没有跑偏。

---

2.11 Hooks

Hooks（钩子：自动化与门禁）： 是“事件驱动自动化”，在特定事件发生时自动执行动作（跑脚本、检查、提醒、阻断等）。

怎么用（最常见三类）

• 质量自动化：改完文件自动 format/lint/跑测试。
• 危险拦截：拦截高风险命令、敏感文件写入。
• 收尾验收：在结束前强制输出检查清单/证据（例如必须给 Test Evidence）。

在三套工具里怎么落地（对照）

---

2.12 Tools

Tools（工具 / 工具调用）： 工具是代理的“手脚”，例如读文件、写文件、搜索、运行命令、访问外部系统等。工具让Coding Agent从“猜”变成“查”：

• 读文件减少凭空编造
• 跑测试让它能自证
• grep/搜索加速定位影响面

在三套工具里怎么落地（对照）

---

2.13 Skills

Skills（技能 / SOP）： 是 “标准作业程序（SOP）打包”，把步骤、清单、输出契约、资源（脚本/参考资料）放进一个可复用单元，并按需加载/触发。

Skills vs Prompts（关键区别）

• prompts（自定义提示）更像“可复用话术/模板”，通常需要显式调用，且可能不随仓库共享（具体取决于产品设计）。
• skills 更像“可治理的流程资产”，常见支持：
  • 目录结构（脚本/资源）
  • 渐进式披露（不默认把全文塞进上下文）
  • 团队共享与优先级覆盖

在三套工具里怎么落地（对照）

---

2.14 Plugins / Extensions

Plugins / Extensions（插件/扩展：打包与分发）： 解决的是“把一套能力打包给别人装上就能用”，例如命令、hooks、skills、MCP  配置、甚至 LSP 等。

在三套工具里怎么落地（对照）

---

2.15 MCP

MCP（Model Context Protocol）： 是把外部 “工具/上下文提供者” 接进代理的一种协议 /接口标准，例如很多关键上下文不在代码仓库里（内部文档、工单系统、数据库 schema、设计稿、语言服务器等），MCP 让代理能“按需获取”这些信息，而不是靠你手动复制粘贴。

在三套工具里怎么落地（对照）

---

2.16 LSP

LSP（Language Server Protocol）： 是编辑器/工具与“语言服务进程”沟通的统一协议，常见能力有跳转定义、找引用、类型诊断、补全、重构提示等。它能把“代码理解”从“文本猜测”提升到“语义级导航”：

• 哪个符号定义在哪
• 这个函数被哪里调用
• 类型/诊断信息是什么
  对大仓库尤其有用。

在三套工具里怎么落地（对照）

---

2.17 Sandbox

Sandbox（沙箱）：是 “把代理的可执行动作限制在可控范围” 的隔离环境机制，目的是降低意外修改系统/泄露信息/误操作的风险。当代理能跑命令、能写文件时，沙箱和权限一起构成“底层安全网”。

沙箱通常在隔离什么

• 文件系统范围：只能读/写工作区（或特定目录），防止误伤系统文件。
• 命令执行能力：限制可执行命令、超时、资源上限，避免“跑飞”或误操作。
• 网络与外部访问：有的环境会限制联网或只能访问白名单服务。
• 凭据与环境变量：避免把敏感 token 暴露给不必要的步骤/工具。

在三套工具里怎么落地（对照）

---

2.18 LLM Gateway

LLM gateway（大模型网关）： 是企业/团队常用的一层“统一入口”：把多个模型提供方（或多个模型版本）藏在网关后面，对外提供统一鉴权与调用接口。它通常负责这些工程化能力：

• 路由与选型：根据任务类型选择模型（快/便宜/强推理）。
• 权限与审计：谁在调用、调用了什么、是否触发敏感策略。
• 速率限制与配额：防止滥用与成本失控。
• 日志/追踪/脱敏：便于排障与合规（避免把敏感数据直接打到第三方）。

---

2.19 Agents

Agents（代理 / 后台任务）：不是单纯的模型，而是 “能执行任务的一整套系统”，在 CLI 产品里，常表现为可运行的任务单元（可能能并行、能查看状态）。

在三套工具里怎么落地（对照）

---

2.20 Subagent

Subagent（子代理 / 专职工种）：可以把主代理当 Tech Lead（负责拆解、编排、汇总）， 把 Subagent 当“专职工种”（例如测试工程师、安全审计、文档工程师）。

怎么用（安全边界很关键）

• 给子代理更小的工具权限：
  • 安全审计：Read/Grep 就够了
  • 测试补齐：再给 Write
  • 需要跑命令才给 Bash

---

2.21 Remote Subagents

Remote subagents（远程子代理）： 指“子代理不在当前本地进程/会话里执行”，而是在远程/隔离环境中执行（仍由主代理编排），常用于：

• 并行处理多个子任务
• 更强隔离（安全/资源/网络）
• 把耗时任务放到后台或云端

在三套工具里怎么落地（对照）

---

2.22 AI native team

AI native team（AI 原生团队）：意思不是“用 AI 写代码”，而是把代理纳入 SDLC 的每个环节，让流程天然支持‘代理协作’。

SDLC（软件研发生命周期）： 典型环节为 需求 → 设计 → 实现 → 测试 → 评审 → 发布 → 监控/回滚 → 复盘。

怎么落地（用你现在学到的术语串成一条流水线）

• 需求：用 prompt 模板把 DoD 写清楚（范围/验收/风险）。
• 设计：用 context files 固化约定；必要时用子代理输出设计评审清单。
• 实现：主代理编排，子代理分工（subagents）；工具（tools）落地改动。
• 质量门禁：hooks 自动 format/lint/test；rules/permissions 拦截危险操作；沙箱降低误伤。
• 交付：skills 生成 PR 描述/发布说明（含风险、回滚、测试证据）；必要时通过 MCP 拉取外部信息（工单/文档/语言服务）。
• 回滚与复盘：checkpointing（Git/rewind）+ 结构化日志，确保可追溯。

3. 术语速查表

3.1 输入与指令层（你对 Agent 说什么）

---

3.2 策略与护栏层（能做什么、要不要确认）

---

3.3 上下文层（模型“看见”的是什么）

---

5.4 记忆与复用层（跨回合、跨项目怎么复用）

---

5.5 工程化能力层（让 Agent 变“可交付”）

---

5.6 执行组织层（怎么跑、怎么并行）

---

5.7 基础计量与成本层（为什么会慢、会贵、会跑偏）

---

5.8 协议与集成层（把外部系统接进来）

---

5.9 易混淆对照