AI Native开发落地手册：从AI辅助到Agent驱动的SDLC重构-平芜编程栈

1. 从“AI辅助”到“AI原生”：为什么你的团队需要这本落地手册

过去两年，我参与过十几个团队从零搭建AI研发流程的过程，也见过太多团队卡在同一个地方：工具买了一堆，模型接了好几个，但研发效率没提升多少，反而多了一堆维护成本。问题的根子不在工具，而在范式。大多数团队做的是“AI辅助开发”——在原有流程上挂一个代码补全插件，或者让产品经理用聊天窗口写写需求文档。而AI Native团队的做法完全不同：他们把AI当作研发流程中的一等公民，从需求拆解、方案设计、编码实现到测试验收，每个环节都有Agent参与，人只负责定义目标、审核结果和处理异常。

这个区别听起来像是概念游戏，但实际落地后的差距非常大。我见过一个六人小组，用AI Native的方式三个月完成了一个原本需要十五人半年的项目，代码质量还更稳定。他们的核心做法不是用了什么神秘工具，而是把SDLC（软件开发生命周期）重新设计了一遍，让Agent在每一个阶段都有明确的职责边界和输入输出规范。这套方法论我称之为“AI Native开发落地手册”，它不是某个具体产品的说明书，而是一套可以适配不同技术栈的研发范式。

这篇文章适合三类人：第一类是想在团队内推动AI Native转型的技术负责人，你需要一套能说服老板和同事的完整逻辑；第二类是正在搭建Agent开发流程的一线工程师，你需要可复制的配置和避坑经验；第三类是对Agent、CLAUDE.md、Plan Mode这些概念还比较模糊的开发者，你想知道这些东西在实际项目中到底怎么用、能解决什么问题。我会从整体设计思路讲到具体实操步骤，把每个关键决策背后的原因说清楚，让你看完就能在自己的项目里试起来。

2. AI Native团队的整体设计与核心思路拆解

2.1 传统SDLC和AI Native SDLC的本质区别

传统软件开发生命周期是一条线性流水线：需求分析、系统设计、编码、测试、部署、运维。每个阶段有明确的交付物和评审节点，人负责所有环节的思考和执行。AI Native SDLC不是把这条流水线自动化，而是把它改造成一个“人机协作网络”。在这个网络里，Agent承担大量重复性、模式化的认知工作，人则聚焦在目标定义、边界判断和异常处理上。

我画过一张对比表，放在这里更直观：

维度	传统SDLC	AI Native SDLC
需求阶段	产品经理写PRD，人工评审	Agent根据目标生成需求草案，人审核补充
设计阶段	架构师画图，团队评审	Agent生成多套方案，人选择并调整
编码阶段	开发者逐行编写	Agent按Plan Mode执行，人审核关键节点
测试阶段	测试工程师写用例	Agent自动生成用例并执行，人处理边界情况
文档阶段	事后补写	Agent实时生成并维护CLAUDE.md
知识沉淀	靠个人记忆和零散文档	Agent记忆+项目级知识库自动积累

这个转变的核心在于：Agent不是工具，而是团队成员。它有自己的“工作记忆”（working memory），有明确的职责范围，有输入输出规范。你不需要把它当成一个需要精确指令的机器，而是当成一个需要清晰目标、合理约束和及时反馈的协作者。

2.2 为什么选择Agent而不是简单的AI辅助工具

很多团队一开始会尝试用代码补全工具或者聊天式AI来提升效率，但很快会遇到瓶颈。原因很简单：这些工具是“无状态”的，它们不知道你的项目上下文，不记得上次讨论的架构决策，也无法在多个任务之间保持一致性。而Agent的核心价值在于有状态、有记忆、有执行能力。

我举个例子。假设你要给一个电商系统加一个“限时折扣”功能。用聊天式AI，你需要每次把项目结构、数据库设计、现有代码风格都贴给它，它才能给出还算靠谱的建议。而用Agent，你只需要在项目根目录放一个CLAUDE.md文件，里面写清楚项目结构、技术栈、编码规范、常用命令，Agent就能在后续所有任务中自动读取这些信息。它还能记住上次你否决了某个方案的原因，下次不会再提同样的建议。

这就是为什么AI Native团队必须要有CLAUDE.md这样的项目级配置文件。它相当于Agent的“入职手册”，告诉它这个项目的规矩是什么、边界在哪里、遇到问题找谁。没有这个文件，Agent就像一个每天换新人的团队，永远在重复解释基础信息。

2.3 Plan Mode：让Agent先想清楚再动手

Agent最容易出问题的地方是“自作主张”。你让它加一个功能，它可能直接开始改代码，改到一半发现方向错了，又回头重来。这不仅浪费token，还可能把项目搞乱。Plan Mode就是解决这个问题的关键机制。

Plan Mode的核心思想是：Agent在执行任何实质性操作之前，必须先输出一份详细的执行计划，包括要改哪些文件、每个文件改什么、预期结果是什么、可能的风险点在哪里。人审核通过后，Agent才进入执行阶段。这个机制看起来增加了步骤，但实际上大幅降低了返工率。

我在实际项目中的做法是：把Plan Mode设为默认模式，只有非常明确的小任务（比如改一个变量名、修一个拼写错误）才允许跳过计划直接执行。对于任何涉及多文件、多模块的改动，必须走Plan Mode。审核计划时，我重点关注三件事：第一，Agent是否理解了需求的边界；第二，它选择的方案是否符合项目现有架构；第三，它有没有遗漏异常情况的处理。

2.4 多Agent协作的编排逻辑

单个Agent的能力是有上限的。当项目复杂度上升时，你需要多个Agent分工协作。常见的分工方式有三种：按职能分（需求Agent、设计Agent、编码Agent、测试Agent）、按模块分（前端Agent、后端Agent、数据库Agent）、按任务类型分（重构Agent、新功能Agent、Bug修复Agent）。

我比较推荐的是“按职能分+按模块分”的混合模式。比如在一个Web项目中，可以设置一个“架构Agent”负责整体设计和技术选型，一个“前端Agent”负责UI和交互，一个“后端Agent”负责API和数据逻辑，一个“测试Agent”负责用例生成和执行。每个Agent有自己的CLAUDE.md片段，定义自己的职责范围和协作接口。

这里的关键是编排。Agent之间不能随意通信，必须有明确的输入输出规范。比如前端Agent需要后端API时，不能直接去改后端代码，而是生成一份“接口需求文档”，由架构Agent审核后转给后端Agent。这种约束看起来麻烦，但能避免多Agent互相覆盖代码、产生冲突的问题。

3. 核心细节解析与实操要点

3.1 CLAUDE.md的编写规范与常见误区

CLAUDE.md是AI Native项目的基石文件。它放在项目根目录，Agent每次启动时自动读取。这个文件写得好不好，直接决定了Agent的输出质量。我见过很多团队把CLAUDE.md写成“项目介绍”，这是最大的误区。CLAUDE.md不是给人看的文档，而是给Agent看的“操作手册”。

一份合格的CLAUDE.md应该包含以下内容：

项目结构说明：用简洁的目录树说明每个文件夹的用途，标注哪些是核心代码、哪些是配置文件、哪些是自动生成的。
技术栈和版本：明确列出语言、框架、数据库、中间件的版本号。Agent需要知道它面对的是什么技术环境。
编码规范：命名规则、注释风格、错误处理方式、日志格式。这些规范要具体到可执行的程度，不能只说“保持代码整洁”。
常用命令：构建、测试、部署、代码检查的命令。Agent需要知道怎么验证自己的改动。
边界和禁忌：哪些文件不能改、哪些操作需要人工确认、哪些依赖不能引入。
协作接口：如果有多个Agent，说明每个Agent的职责范围和交接方式。

我自己的项目里，CLAUDE.md通常控制在200到400行之间。太短了信息不够，太长了Agent读取效率下降。关键是要把“必须知道”和“最好知道”分开，必须知道的内容放在前面，最好知道的内容放在后面。

注意：CLAUDE.md不是一次写完就固定的。每次Agent犯了一个“本不该犯”的错误，就应该反思是不是CLAUDE.md里缺少了相应的约束，然后补充进去。这个文件是活的，需要持续维护。

3.2 Agent记忆机制的设计与working memory管理

Agent的“记忆”分为短期记忆和长期记忆。短期记忆就是当前会话的上下文，长期记忆则是跨会话的知识积累。很多Agent框架都提供了working memory机制，但默认配置往往不够用。你需要根据项目特点来设计记忆的存储和检索方式。

我的做法是把记忆分成三层：

第一层是会话记忆，保存在当前对话的上下文中，用于维持当前任务的连贯性。这部分不需要额外配置，但要注意控制长度，太长了会影响Agent的响应速度。

第二层是项目记忆，保存在项目目录下的.agent/memory/文件夹中，按主题分类存储。比如architecture.md记录架构决策，conventions.md记录编码约定，issues.md记录已知问题和解决方案。Agent在需要时可以主动检索这些文件。

第三层是跨项目记忆，保存在用户主目录下的全局配置中，记录个人偏好和通用经验。这部分要谨慎使用，避免把某个项目的特定规则带到其他项目中。

working memory的管理关键是“写入时机”和“检索策略”。写入时机方面，我建议在以下三个时刻触发记忆写入：完成一个完整任务后、做出重要决策后、发现并解决一个非显而易见的问题后。检索策略方面，不要每次都把所有记忆都加载进来，而是根据当前任务的关键词进行匹配检索。

3.3 Plan Mode的实操配置与审核要点

Plan Mode的配置因Agent框架而异，但核心逻辑是相通的。以我常用的配置为例，在Agent的配置文件中设置plan_mode: required，并定义触发条件：当任务涉及超过3个文件、或者涉及数据库schema变更、或者涉及外部API集成时，强制进入Plan Mode。

Agent在Plan Mode下输出的计划应该包含以下要素：

任务理解：用一两句话复述它理解的需求，确保没有偏差。
影响范围：列出所有需要改动的文件和模块。
执行步骤：按顺序列出每一步做什么，每步的预期结果是什么。
验证方式：怎么确认改动是正确的，需要跑哪些测试。
风险提示：可能影响哪些现有功能，有什么回滚方案。

审核计划时，我重点关注三个“不一致”：计划中的技术方案和项目现有架构是否一致、计划的粒度和需求复杂度是否一致、计划的验证方式和项目测试规范是否一致。如果发现不一致，不要直接让Agent重新计划，而是指出具体哪里不一致，让它针对性调整。

提示：Plan Mode下Agent可能会输出非常详细的计划，这时候不要嫌麻烦。审核计划花五分钟，可能省下半小时的返工时间。我自己的经验是，Plan Mode审核越认真，执行阶段出问题的概率越低。

3.4 多Agent编排的接口设计与冲突避免

多Agent协作最容易出的问题是“互相踩脚”。两个Agent同时改同一个文件，或者一个Agent的改动破坏了另一个Agent的假设。避免这类问题的核心是接口设计和变更通知。

接口设计方面，每个Agent的输入输出都要有明确的格式。比如前端Agent需要后端API时，输出一份JSON格式的接口需求：

{ "endpoint": "/api/discount/active", "method": "GET", "params": {"product_id": "string"}, "response": {"discount_rate": "number", "end_time": "string"}, "notes": "需要支持缓存，过期时间5分钟" }

后端Agent收到这份需求后，按格式实现并返回接口文档。架构Agent负责审核接口是否符合整体设计。

变更通知方面，我建议在项目根目录维护一个CHANGELOG_AGENT.md文件，每个Agent完成实质性改动后，在这里追加一条记录：谁改了什么、为什么改、影响了哪些模块。其他Agent在执行任务前先读这个文件，了解最近的变更。

冲突避免的另一个关键是文件锁。对于核心配置文件（如数据库schema、路由配置），同一时间只允许一个Agent修改。可以在Agent配置中设置exclusive_files列表，列表中的文件需要申请锁才能修改。

4. 实操过程与核心环节实现

4.1 从零搭建AI Native项目的完整步骤

假设你现在要启动一个新项目，或者把现有项目改造成AI Native模式。以下是我实际用过的步骤，按顺序执行即可。

第一步：初始化项目结构。在项目根目录创建以下文件：

project-root/ ├── CLAUDE.md # Agent操作手册 ├── .agent/ │ ├── config.yaml # Agent配置 │ ├── memory/ # 项目记忆 │ │ ├── architecture.md │ │ ├── conventions.md │ │ └── issues.md │ └── plans/ # Plan Mode输出存档 ├── CHANGELOG_AGENT.md # Agent变更日志 └── src/ # 项目代码

第二步：编写CLAUDE.md。按3.1节的规范，把项目结构、技术栈、编码规范、常用命令、边界禁忌写清楚。第一版不用追求完美，先把最核心的信息写进去，后续根据Agent的表现逐步补充。

第三步：配置Agent。在.agent/config.yaml中设置Agent的基本参数：

agent: name: "dev-agent" model: "claude-sonnet" plan_mode: required max_context_tokens: 100000 memory: project_memory_path: ".agent/memory/" auto_write: true write_triggers: - task_complete - decision_made - issue_resolved exclusive_files: - "src/config/database.yaml" - "src/routes/index.ts"

第四步：定义第一个任务。从一个小而完整的任务开始，比如“给用户列表页加一个搜索框”。任务描述要包含：目标是什么、涉及哪些页面、期望的交互效果、有什么约束条件。然后让Agent进入Plan Mode，输出执行计划。

第五步：审核计划并执行。按3.3节的要点审核计划，确认无误后让Agent执行。执行过程中，Agent每完成一个关键步骤会输出进度，你可以随时介入调整。

第六步：验收和记忆写入。任务完成后，检查代码质量、跑测试、确认功能符合预期。然后让Agent把这次任务中的关键决策和经验写入项目记忆。

第七步：迭代优化。每完成几个任务，回顾一下CLAUDE.md是否需要补充、Agent配置是否需要调整、记忆文件是否需要整理。这个迭代过程通常持续两到三周，之后Agent的表现会趋于稳定。

4.2 一个完整任务的Agent执行记录

我拿一个真实任务来演示：给一个博客系统加“文章草稿自动保存”功能。任务描述是：“用户编辑文章时，每30秒自动保存草稿到本地存储，刷新页面后能恢复未发布的草稿。”

Agent在Plan Mode下输出的计划如下：

任务理解：实现文章编辑器的草稿自动保存和恢复功能。 影响范围： - src/components/Editor.tsx（编辑器组件） - src/hooks/useAutoSave.ts（新建，自动保存逻辑） - src/utils/storage.ts（本地存储工具） - src/pages/EditPage.tsx（编辑页面） 执行步骤： 1. 在storage.ts中添加草稿的保存、读取、删除方法 2. 创建useAutoSave hook，实现30秒定时保存逻辑 3. 在Editor组件中集成useAutoSave，监听内容变化 4. 在EditPage中加载时检查是否有草稿，有则提示恢复 5. 发布文章后清除草稿 验证方式： - 单元测试：storage.ts的增删改查 - 集成测试：模拟编辑30秒后检查localStorage - 手动测试：编辑后刷新页面，确认草稿恢复 风险提示： - 草稿可能和已发布内容冲突，需要明确优先级 - 多个标签页同时编辑可能互相覆盖

我审核这份计划时，发现两个问题：第一，没有考虑草稿的版本管理，如果用户在不同设备上编辑，可能覆盖；第二，没有说明草稿的过期策略，本地存储可能无限增长。我把这两个问题反馈给Agent，它调整了计划：增加草稿时间戳和版本号，设置草稿保留7天自动清理。

执行阶段，Agent按步骤完成了代码。我重点检查了useAutoSave hook的实现，发现它用了setInterval但没有在组件卸载时清理，这是一个常见的内存泄漏问题。我让Agent修复后，它补充了clearInterval的清理逻辑。

任务完成后，Agent自动把这次的经验写入了.agent/memory/issues.md：

## 自动保存功能的注意事项 - setInterval必须在组件卸载时清理，否则内存泄漏 - 本地存储的草稿需要设置过期时间，避免无限增长 - 多标签页场景需要加锁或版本号机制

这条记忆在后续类似任务中被Agent自动检索到，避免了重复踩坑。

4.3 参数计算与选择过程

AI Native项目中涉及不少参数选择，我挑几个关键的说明计算逻辑。

上下文窗口大小：Agent的上下文窗口决定了它能同时处理多少信息。我的经验公式是：所需上下文 = 项目CLAUDE.md大小 + 当前任务相关文件总大小 + 记忆检索结果大小 + 对话历史大小。如果这个值接近模型上限的80%，就需要考虑拆分任务或者精简CLAUDE.md。比如一个中型项目，CLAUDE.md约3000token，相关文件约20000token，记忆约2000token，对话历史约5000token，总计30000token。如果模型支持100000token，那还有充足余量。

Plan Mode的触发阈值：我设置的是“涉及文件数超过3个”或“涉及数据库变更”或“涉及外部API”。这个阈值可以根据团队情况调整。如果团队对Agent信任度高，可以放宽到5个文件；如果项目风险敏感，可以收紧到2个文件。

记忆写入频率：太频繁会拖慢Agent响应，太稀疏会丢失重要信息。我的做法是设置“最小写入间隔”为10分钟，同时要求“任务完成”和“问题解决”必须写入。这样既不会频繁打断，也不会遗漏关键节点。

多Agent并发数：不是越多越好。我的经验是，对于大多数项目，2到3个Agent并行比较合适。超过3个，协调成本会急剧上升。如果任务确实需要更多并行，建议按模块拆分，每个模块内部串行，模块之间并行。

4.4 工具选型与集成要点

Agent框架的选择上，我试过不少方案。核心考量三个维度：记忆管理能力、Plan Mode支持程度、多Agent编排灵活性。有些框架记忆管理强但Plan Mode弱，有些编排灵活但配置复杂。我的建议是先用一个轻量框架跑通单Agent流程，确认团队适应后再考虑多Agent。

集成方面，最重要的是和现有工具链的对接。Agent需要能调用代码检查工具、测试框架、构建工具。我的做法是在CLAUDE.md中定义“标准命令”，Agent通过执行这些命令来验证自己的改动。比如：

# 代码检查 npm run lint # 单元测试 npm run test:unit # 构建验证 npm run build

Agent在执行任务后会自动跑这些命令，如果失败则根据错误信息自行修复。这个闭环非常重要，它让Agent有了“自我验证”的能力，而不是完全依赖人工检查。

5. 常见问题与排查技巧实录

5.1 Agent执行中断与错误恢复

Agent执行过程中最常见的错误是“execution terminated due to error”。这类错误通常有三类原因：上下文超限、工具调用失败、逻辑死循环。

上下文超限的典型表现是Agent突然开始重复之前的内容，或者输出变得混乱。排查方法是检查当前会话的token数，如果接近模型上限，就需要清理对话历史或者拆分任务。我的做法是在Agent配置中设置max_context_tokens为模型上限的70%，留出30%的余量。

工具调用失败的表现是Agent反复尝试同一个命令但一直报错。排查方法是查看具体报错信息，常见原因包括：命令不存在、权限不足、依赖缺失。解决方式是在CLAUDE.md中补充环境要求，或者在Agent配置中增加错误重试策略。

逻辑死循环的表现是Agent在两个方案之间反复切换，或者不断修改同一个文件但问题依旧。排查方法是查看Plan Mode的输出，确认Agent是否真正理解了任务。解决方式是中断执行，重新描述任务，明确约束条件。

注意：Agent出错时不要直接重启任务，先让它输出当前状态和遇到的问题。很多时候Agent能自己诊断出原因，你只需要给它一个提示。

5.2 多Agent冲突的排查与解决

多Agent冲突的典型表现是：代码被意外覆盖、接口不匹配、测试突然失败。排查步骤是：先看CHANGELOG_AGENT.md，确认最近有哪些Agent做了改动；然后看冲突文件的具体diff，定位是哪个Agent的改动导致了问题；最后看相关Agent的Plan Mode记录，确认它的执行计划是否合理。

解决冲突的原则是“先回滚，再协调”。不要试图在冲突状态下继续推进，先把有问题的改动回滚到上一个稳定状态，然后让相关Agent重新协调接口。协调时，架构Agent要出面明确接口规范，避免再次冲突。

预防冲突的措施包括：设置exclusive_files锁、要求Agent在改动核心文件前先发通知、定期同步各Agent的记忆文件。我自己的项目里，每天结束前会让所有Agent输出一份“今日改动摘要”，人工检查是否有潜在冲突。

5.3 Agent输出质量不稳定的调优方法

Agent输出质量不稳定通常有三个原因：CLAUDE.md不够具体、任务描述不够清晰、记忆检索不准确。

CLAUDE.md不够具体的表现是Agent经常做出“本不该做”的改动。解决方法是补充边界和禁忌，把“不要做什么”写清楚。比如“不要引入新的第三方依赖”、“不要修改数据库schema”、“不要改变现有API的响应格式”。

任务描述不够清晰的表现是Agent的理解和你的预期有偏差。解决方法是采用“目标+约束+验收标准”的格式描述任务。目标说清楚要达成什么，约束说清楚不能突破什么，验收标准说清楚怎么算完成。

记忆检索不准确的表现是Agent重复犯同样的错误，或者忽略了之前的重要决策。解决方法是优化记忆文件的组织方式，按主题分类，每个文件开头写摘要，方便Agent快速定位。

5.4 常见问题速查表

问题现象	可能原因	排查方法	解决措施
Agent重复输出相同内容	上下文超限	检查token数	清理历史或拆分任务
Agent反复执行同一命令	工具调用失败	查看报错信息	补充环境配置或重试策略
代码被意外覆盖	多Agent冲突	查看CHANGELOG	回滚后协调接口
Agent理解偏差	任务描述模糊	对比Plan和预期	重新描述任务
重复犯同样错误	记忆未生效	检查记忆文件	优化记忆组织
执行速度突然变慢	记忆文件过大	检查文件大小	精简记忆内容
Plan Mode输出过于简略	配置阈值过低	检查触发条件	调整触发阈值
Agent拒绝执行任务	边界约束过严	查看CLAUDE.md	调整约束条件

5.5 独家避坑经验分享

第一个坑是“过度依赖Agent”。有些团队把Agent当成万能工具，什么任务都丢给它，结果质量参差不齐。我的经验是：Agent适合处理模式化、有明确规范的任务；对于需要创造性判断、涉及复杂权衡的任务，人还是要深度参与。一个简单的判断标准是：如果这个任务你能写出清晰的步骤和验收标准，就可以交给Agent；如果你自己都说不清楚要怎么做，那就先自己想清楚再交给Agent。

第二个坑是“CLAUDE.md写得太长”。我见过一个团队的CLAUDE.md写了上千行，结果Agent读取效率很低，经常忽略后面的内容。CLAUDE.md的核心信息应该控制在300行以内，详细内容可以拆到.agent/memory/下的专题文件中，Agent按需检索。

第三个坑是“忽略Agent的记忆维护”。记忆文件如果长期不整理，会积累大量过时信息，导致Agent检索到错误的内容。我的做法是每周花15分钟整理一次记忆文件，删除过时条目，合并重复内容，更新摘要。

第四个坑是“Plan Mode审核走过场”。有些团队觉得Plan Mode太麻烦，审核时随便看一眼就通过。结果执行阶段出了问题，返工成本更高。我的经验是：Plan Mode审核时间应该占整个任务时间的10%到15%。一个预计执行30分钟的任务，花3到5分钟审核计划是合理的。

第五个坑是“多Agent没有明确的交接规范”。Agent之间传递任务时，如果没有统一的格式，很容易丢失关键信息。我的做法是定义一套“任务交接模板”，包含：任务目标、输入文件、输出要求、约束条件、验收标准。每个Agent在交接时按模板填写，接收方按模板检查。

6. 从单Agent到多Agent的演进路线

6.1 什么阶段该引入多Agent

不是所有项目都需要多Agent。我的判断标准是：当单Agent的上下文经常超限、或者任务等待时间明显变长、或者不同模块的规范差异大到需要分别配置时，就该考虑多Agent了。

具体来说，如果你发现Agent经常需要同时处理前端和后端代码，而这两部分的编码规范差异很大，单Agent容易混淆，那就该拆分。或者如果你发现Agent在处理大型任务时经常“忘记”前面的决策，那也是上下文超限的信号。

引入多Agent的时机也很重要。不要在项目初期就上多Agent，那时候你对项目的理解还不够深，拆分方式可能不合理。我的建议是先用单Agent跑通至少10个完整任务，积累足够的CLAUDE.md内容和记忆文件，然后再根据实际痛点拆分。

6.2 多Agent架构的渐进式演进

演进路线我建议分三步走：

第一步：单Agent+多记忆文件。还是一个Agent，但把记忆按模块拆分到不同文件。Agent根据任务类型检索对应的记忆文件。这一步不需要改架构，只需要调整记忆组织方式。

第二步：双Agent+明确分工。拆成两个Agent，比如一个负责“代码实现”，一个负责“测试和验证”。两个Agent共享CLAUDE.md和记忆文件，但各有自己的配置。这一步的关键是定义好交接接口。

第三步：多Agent+编排层。拆成三个或更多Agent，引入一个“编排Agent”负责协调。编排Agent不直接写代码，而是负责任务分配、进度跟踪、冲突处理。这一步需要更复杂的配置，但能支撑更大的项目规模。

每一步演进后，都要观察一到两周，确认稳定性后再进入下一步。不要一次性拆得太细，否则协调成本会超过收益。

6.3 企业级Agent平台的考量因素

如果团队规模较大，可能需要考虑企业级的Agent平台。选型时我关注五个维度：

第一是权限管理。不同角色的成员对Agent的控制权限应该不同。比如初级开发者只能让Agent执行Plan Mode审核通过的任务，高级开发者可以调整Agent配置。

第二是审计日志。所有Agent的操作都要有记录，包括谁发起的任务、Agent做了什么改动、什么时候改的。这对排查问题和合规审查很重要。

第三是知识库集成。企业通常有内部文档、代码规范、历史项目资料，Agent平台应该能对接这些知识库，让Agent在需要时检索。

第四是成本控制。Agent调用模型是有成本的，平台应该提供token消耗统计和预算控制功能。我的经验是，一个中型项目每月的Agent成本大约在几百到几千元之间，具体取决于任务量和模型选择。

第五是安全边界。Agent不能访问敏感数据，不能执行危险操作。平台应该提供细粒度的权限控制和操作白名单。

6.4 Agent评测与持续优化

Agent的表现需要定期评测。我自己的评测方法是：每月选5到10个典型任务，让Agent执行，记录成功率、返工率、人工介入次数。然后对比上个月的数据，看是否有提升。

评测维度包括：任务理解准确率（Plan Mode输出是否符合预期）、执行成功率（一次通过的比例）、代码质量（lint通过率、测试覆盖率）、效率提升（相比人工完成的耗时对比）。

优化方向根据评测结果确定。如果任务理解准确率低，就优化CLAUDE.md和任务描述模板；如果执行成功率低，就优化Plan Mode审核流程和错误恢复策略；如果代码质量不稳定，就补充编码规范和自动化检查。

这个评测和优化循环应该持续进行。我自己的项目跑了半年，Agent的一次通过率从最初的40%提升到了75%左右，人工介入时间减少了60%。这个提升不是靠换模型，而是靠持续优化配置和记忆。

7. 一些实操中的个人体会

这套AI Native开发手册在我自己的项目中跑了大半年，最大的感受是：Agent的能力上限不取决于模型，而取决于你怎么用它。同样的模型，配置得当的Agent能完成80%的常规开发任务，配置不当的连一个简单的重构都做不好。

另一个体会是：不要追求全自动化。有些团队想把整个SDLC都交给Agent，人只做最后验收。实际跑下来，这种做法风险很高。我的建议是保持“人在回路”的节奏，关键决策必须人工审核，异常情况必须人工处理。Agent负责的是“执行”，人负责的是“判断”。

还有一个很实际的体会：CLAUDE.md和记忆文件的维护比想象中重要。我一开始也觉得这些是“额外工作”，但后来发现，花在维护这些文件上的时间，远远少于因为Agent理解偏差导致的返工时间。现在我把CLAUDE.md的维护当成项目的一部分，每次迭代都会更新。

最后分享一个小技巧：给Agent设置一个“每日回顾”任务，让它每天结束时输出一份“今日工作总结”，包括完成了什么、遇到了什么问题、有什么建议。这份总结不仅帮你了解Agent的工作状态，还能作为记忆写入的素材。我坚持跑了三个月，Agent的“自我认知”明显提升，很多问题在发生前就被它自己识别出来了。

AI Native开发落地手册：从AI辅助到Agent驱动的SDLC重构