AI Native团队落地指南：Agent、Harness与Plan Mode实战

1. 为什么“AI Native 团队”不是加个 Copilot 那么简单

这两年我参与过几个团队从传统研发模式往 AI Native 方向转的过程，也踩了不少坑。最直观的感受是：绝大多数团队对“AI Native”的理解还停留在“给 IDE 装个补全插件”或者“让 AI 帮忙写写单测”这个层面。这不叫 AI Native，这叫“AI 辅助”。真正的 AI Native 团队，是把 AI 当成研发流程里的一等公民——不是工具，是协作者，甚至是流程的驱动者。

先把这个概念说清楚。AI Native SDLC（Software Development Life Cycle，软件开发生命周期）指的是从需求拆解、方案设计、编码、测试、Code Review 到部署运维的每一个环节，都默认有 AI Agent 参与，并且人类和 Agent 之间有明确的协作协议和边界。它和“用 AI 提效”最大的区别在于：前者是流程重构，后者是工具叠加。

我见过太多团队买了企业版账号、配了 API Key，然后呢？然后就没有然后了。开发同学该手写还是手写，AI 只在偶尔想起来的时候问两句。问题出在哪？出在没有把 AI 嵌入到流程的强制节点上。你指望人自觉去用，那是不可能的，因为人的惯性太强了。真正跑通的团队，都是把 AI 的输出变成了流程的“必经之路”——比如 PR 必须经过 Agent 初审、需求文档必须由 Agent 先做一轮拆解、代码提交前 Agent 自动跑一遍规范检查。

这套手册要讲的，就是怎么把这件事落地。适合谁来读？三类人：一是正在推动团队 AI 转型的技术负责人，二是想搞清楚 AI Native 到底怎么玩的资深工程师，三是对 Agent 编排、CLAUDE.md、Plan Mode 这些具体机制好奇的开发者。不管你现在团队是三个人还是三百人，下面的思路都能直接抄。

2. 核心概念拆解：Agent、Harness、Plan Mode 到底啥关系

在动手之前，得先把几个高频词掰扯清楚。我发现很多人聊 Agent 的时候，其实脑子里想的是不同的东西，导致讨论完全对不上。

2.1 Agent 不是“更聪明的函数调用”

Agent这个词被用烂了。我的定义是：Agent 是一个能感知上下文、能做决策、能调用工具、能根据反馈调整下一步动作的执行单元。注意关键词是“决策”和“调整”。一个只会按固定顺序调 API 的东西，那叫 workflow，不叫 Agent。

举个生活化的类比。你去餐厅点菜，服务员记下菜单传给后厨——这是 workflow，固定流程。但如果服务员发现你今天嗓子哑了，主动建议你换个清淡的汤，还帮你把辣菜换掉——这才是 Agent，它在感知、判断、决策。

在研发场景里，Agent 的典型形态是：你给它一个任务（比如“修复这个登录超时的 bug”），它会自己去读代码、定位问题、写修复方案、改代码、跑测试、根据测试结果决定要不要再改一轮。整个过程你只给了个目标，中间步骤它自己编排。

2.2 Harness 和 Agent 的区别，一句话讲透

热词里有个“harness和agent区别”，这个问题问得特别好。Harness 是“马具”，是约束和驱动 Agent 的那套框架。Agent 是那匹马，Harness 是缰绳、鞍具、以及你指挥它的那套指令系统。

具体到工程上，Harness 通常包含：上下文注入机制（给 Agent 喂什么信息）、工具注册与权限控制（Agent 能用哪些工具、能碰哪些文件）、执行循环控制（什么时候停、什么时候重试）、以及输出解析（怎么把 Agent 的自然语言输出变成结构化动作）。

为什么这个区分重要？因为很多团队一上来就想“自己写个 Agent”，结果写出来的其实是个 Harness 都没搭好的半成品。我的建议是：先选一个成熟的 Harness，把 Agent 跑起来，再考虑定制。市面上主流的 Agent 框架（比如基于 Claude 的 Agent Skills、Spring AI Agent、ADK 等）本质上都是在提供 Harness 能力。

2.3 Plan Mode：让 Agent 先想后做

Plan Mode是我个人认为最被低估的一个机制。它的核心思想是：Agent 在执行任务前，先输出一份计划，人类确认或修改后再执行。

为什么这个机制关键？因为 Agent 最大的风险不是能力不够，而是方向跑偏。你让它优化性能，它给你重构了整个模块；你让它修个 bug，它顺手改了三个不相关的文件。Plan Mode 就是给 Agent 装了个“刹车”——先看它打算怎么干，不对就拦下来。

实操中，Plan Mode 的粒度可以调。粗粒度就是“我打算分三步：先定位、再修复、后验证”；细粒度可以细到“我打算改第 42 行的这个判断条件，理由是……”。我一般建议在复杂任务上用细粒度，简单任务上粗粒度甚至关掉，不然效率反而低。

2.4 CLAUDE.md：给 Agent 的“团队说明书”

CLAUDE.md这个文件，本质上是放在项目根目录的一份“给 AI 看的 README”。它告诉 Agent：这个项目是干什么的、代码规范是什么、哪些目录不能碰、常用的命令有哪些、遇到问题找谁。

我见过最离谱的情况是：团队花大力气搭了 Agent 环境，结果 Agent 每次都要重新“猜”项目结构，输出的代码风格和团队规范完全不符。问题就出在没有 CLAUDE.md。这份文件的价值在于把隐性的团队知识显性化，让 Agent 每次启动就能站在“老员工”的视角干活，而不是“新来的实习生”。

一份好的 CLAUDE.md 应该包含：项目一句话简介、技术栈清单、目录结构说明、代码风格约定（缩进、命名、注释规范）、构建与测试命令、禁止操作清单（比如“不要动 migrations 目录”）、以及常见任务的执行路径。下面给个模板参考。

# 项目：订单服务 ## 技术栈 - 语言：Go 1.22 - 框架：Gin + GORM - 数据库：PostgreSQL 15 - 测试：testify + mockery ## 目录约定 - /internal/domain：领域模型，禁止引入外部依赖 - /internal/handler：HTTP 层，只做参数校验和响应封装 - /migrations：数据库迁移，Agent 禁止修改 ## 代码规范 - 错误必须 wrap，使用 fmt.Errorf("xxx: %w", err) - 所有导出函数必须有注释 - 单测覆盖率不低于 70% ## 常用命令 - 构建：make build - 测试：make test - 本地起服务：make run ## 禁止事项 - 不要修改 go.mod 中的依赖版本 - 不要删除任何已有的测试用例 - 不要直接操作生产数据库

这份文件写好了，Agent 的输出质量会有肉眼可见的提升。我实测下来，加了 CLAUDE.md 之后，Agent 生成的代码需要人工修改的比例从大概 40% 降到了 15% 左右。

3. AI Native SDLC 的完整流程设计

概念清楚了，接下来是重头戏：怎么把 AI 嵌到整个研发生命周期里。我把它拆成五个阶段，每个阶段说清楚人类和 Agent 的分工。

3.1 需求阶段：Agent 做拆解，人类做决策

传统流程里，需求从产品经理传到开发，中间损耗巨大。AI Native 的做法是：需求文档一出来，先让 Agent 做一轮拆解，输出技术任务清单、影响范围分析、以及潜在风险点。

具体怎么操作？把需求文档丢给 Agent，配上这样的指令：“请把这个需求拆解成可执行的技术任务，每个任务标注：涉及模块、预估工作量、依赖关系、风险等级。同时列出这个需求可能影响的现有功能。”

Agent 输出的东西不一定全对，但它的价值在于提供一个起点。人类工程师在这个基础上做增删改，比从零开始快得多。我自己的经验是，需求拆解环节能省掉大概 60% 的梳理时间。

这里有个坑要注意：不要让 Agent 直接决定优先级。优先级涉及业务判断、资源协调、政治因素，这些是 Agent 搞不定的。Agent 负责“拆”，人类负责“排”。

3.2 设计阶段：Plan Mode 的主场

设计阶段是 Plan Mode 发挥最大价值的地方。让 Agent 针对每个任务输出技术方案，人类 Review 后再进入编码。

一个典型的设计阶段 Agent 指令长这样：“针对任务 T-001（用户登录增加短信验证），请输出技术方案，包含：接口设计、数据模型变更、涉及的服务和模块、异常处理策略、测试要点。不要写代码，只输出方案。”

Agent 会给你一份结构化的方案。这时候人类的角色是评审者，重点看三件事：方案是否符合现有架构、有没有遗漏的边界情况、有没有过度设计。我见过 Agent 把简单需求做成微服务的，所以“过度设计”这个检查项一定要有。

方案确认后，让 Agent 把方案写入一个design/T-001.md文件。这个文件后续会成为编码阶段的上下文，也会成为 Code Review 的参照。

3.3 编码阶段：Agent 写，人类审

编码阶段的分工，我的建议是Agent 写主体，人类写关键逻辑。什么叫关键逻辑？涉及资金、权限、数据一致性的部分，人类必须亲自把关。其余的业务逻辑、CRUD、工具函数，交给 Agent 完全没问题。

实操流程是这样的：Agent 根据 design 文档和 CLAUDE.md 生成代码，人类在 IDE 里 Review。Review 的重点不是“代码能不能跑”，而是“代码是不是符合预期”。因为 Agent 写的代码通常能跑，但可能跑得不是你想要的。

这里有个技巧：让 Agent 分批次提交，而不是一次性生成一大堆。比如先让它写数据模型，确认后再写 service 层，再确认后写 handler 层。这样每批的 Review 成本低，出问题也容易定位。

3.4 测试阶段：Agent 是主力

测试是 Agent 最能发挥优势的环节，因为测试用例的生成有很强的模式性。让 Agent 根据代码和 design 文档生成单测、集成测试，人类补充边界用例。

我一般会这样指令 Agent：“为 internal/service/order.go 生成单元测试，覆盖正常流程、参数校验失败、数据库错误三种场景。使用 testify，mock 掉 repository 层。”

Agent 生成的测试通常能覆盖 70% 左右的场景，剩下的 30% 是那些“只有老员工才知道”的边界情况，需要人类补充。但即便如此，测试编写的时间也能省掉一半以上。

3.5 部署与运维：Agent 做巡检，人类做决策

部署阶段，Agent 可以做的是：生成部署脚本、检查配置一致性、分析部署日志、发现异常时告警。但不要让 Agent 自动执行生产部署，这个红线必须守住。

运维阶段，Agent 可以做日志分析、异常聚类、根因初判。比如线上报错激增，Agent 可以先把错误日志聚类，输出“80% 的错误来自同一个空指针，发生在 order 模块”，人类再基于这个线索去定位。

4. 落地实操：从零搭一套 AI Native 工作流

前面讲的是设计思路，这一节讲具体怎么搭。我按“环境准备 → 配置 → 跑通第一个任务”的顺序来。

4.1 环境准备与工具选型

工具选型这块，我的原则是先跑通再优化。不要一上来就纠结用哪个框架，先用最成熟的方案把流程跑起来。

选型时最容易踩的坑是追求“全家桶”。有些团队非要找一个能覆盖所有环节的单一平台，结果发现每个环节都不好用。我的建议是分环节选最优，用脚本或 Hook 把它们串起来。

4.2 CLAUDE.md 的编写要点

前面给了模板，这里补充几个编写要点。

第一，命令要具体到可直接复制。不要写“运行测试”，要写“make test”或者“go test ./... -cover”。Agent 不需要你教它什么是测试，它需要的是这个项目里测试命令到底是什么。

第二，禁止事项要明确。Agent 很听话，你说不让动它就不动。但如果你没说，它可能就会动。所以“不要修改 X”“不要删除 Y”这类约束一定要写清楚。

第三，保持更新。项目结构变了、命令变了、规范变了，CLAUDE.md 要同步更新。我见过 CLAUDE.md 半年没更新，Agent 还在用老命令，结果一直报错。

4.3 跑通第一个 Agent 任务

选一个简单的任务练手，比如“给现有函数补充注释”或者“修复一个明显的 lint 错误”。目的是熟悉 Agent 的工作节奏和输出风格。

具体步骤：

1. 在项目根目录创建 CLAUDE.md，填入基本信息
2. 打开 Agent 工具，确认它能读到 CLAUDE.md
3. 输入任务：“请为 internal/utils/string.go 中的所有导出函数补充 GoDoc 注释，遵循项目现有注释风格”
4. 观察 Agent 的输出，检查是否符合预期
5. 如果不符合，调整指令或补充 CLAUDE.md 中的规范说明

这个练手任务的价值在于建立信任和手感。你会逐渐知道 Agent 在什么任务上靠谱、什么任务上需要盯紧。

4.4 把 Agent 嵌入 Git 工作流

这是让 AI Native 真正落地的关键一步。做法是在 Git Hook 里加一个 Agent 初审环节。

具体来说，在pre-push或 CI 的 PR 检查里，加一个步骤：调用 Agent 对 diff 做初审，输出一份检查报告。报告内容包括：代码风格是否符合规范、有没有明显的逻辑问题、有没有遗漏的测试、有没有触碰禁止修改的文件。

这份报告不阻断流程，但会作为 PR 的评论展示出来。人类 Reviewer 看到报告后，可以更快地定位问题。我实测下来，这个机制能让 Code Review 的时间缩短大概 30%，因为很多低级问题 Agent 已经帮你筛掉了。

5. 常见问题与避坑指南

这一节是我踩过的坑的总结，都是真金白银换来的经验。

5.1 Agent 输出不稳定怎么办

这是最高频的问题。同一个任务，今天跑得好，明天跑得差。原因通常有三个：上下文不一致、指令模糊、模型本身的随机性。

解决办法：固定上下文 + 明确指令 + 多次采样。固定上下文就是确保每次任务都带上 CLAUDE.md 和相关的 design 文档。明确指令就是避免“优化一下”这种模糊说法，改成“把时间复杂度从 O(n²) 降到 O(n log n)”。多次采样就是同一个任务让 Agent 跑 2-3 次，取最好的结果。

5.2 Agent 改坏了代码怎么回滚

这个必须有预案。我的做法是：Agent 的每次修改都单独提交，commit message 里标注[agent]。这样一旦发现问题，git revert就能精准回滚，不会影响人类的修改。

另外，Agent 操作前先git stash或者建个临时分支，也是个好习惯。我一般让 Agent 在agent/xxx分支上干活，确认没问题再合并。

5.3 团队抵触怎么破

这是组织问题，不是技术问题。我的经验是：别强推，先做样板。找一个愿意尝试的同学，让他先用起来，跑出效果后在团队里分享。人都是看到实际收益才会动心的。

另外，降低使用门槛很关键。如果每次用 Agent 都要配一堆环境、写一堆配置，没人会坚持。把常用任务做成脚本或者快捷指令，一键触发，接受度会高很多。

5.4 常见问题速查表

5.5 几个反直觉的经验

第一个反直觉的点：Agent 不是越强越好。有时候用弱一点的模型反而更可控，因为强模型容易“自作主张”。在需要严格遵循规范的场景下，可控性比能力更重要。

第二个反直觉的点：Plan Mode 不是越细越好。细到每一行代码的计划，人类 Review 的成本比直接看代码还高。找到那个“刚好能拦住方向性错误”的粒度就行。

第三个反直觉的点：不是所有环节都适合 AI。涉及架构决策、跨团队协调、模糊需求澄清的环节，人类的价值不可替代。AI Native 不是“全 AI”，是“该 AI 的地方 AI”。

6. 进阶：多 Agent 协作与并发处理

当单个 Agent 跑通后，自然会想：能不能多个 Agent 一起干活？这就是多 Agent 协作。但我要先泼盆冷水：多 Agent 的复杂度是指数级上升的，没跑通单 Agent 之前不要碰。

6.1 多 Agent 的典型编排模式

目前主流的多 Agent 编排有三种模式。

流水线模式：Agent A 的输出是 Agent B 的输入，依次传递。比如需求拆解 Agent → 方案设计 Agent → 编码 Agent → 测试 Agent。这种模式简单可控，适合流程明确的场景。

并行模式：多个 Agent 同时处理不同子任务，最后汇总。比如一个大重构，拆成五个模块，五个 Agent 并行改。这种模式效率高，但汇总和冲突处理是难点。

辩论模式：两个 Agent 对同一个问题给出方案，互相 Critic，人类做最终裁决。这种模式适合方案设计阶段，能暴露更多盲点。

6.2 并发场景下的冲突处理

多个 Agent 同时改代码，冲突是必然的。处理策略有三层。

第一层是文件级隔离：不同 Agent 负责不同目录，从物理上避免冲突。这是最简单的做法，但适用范围有限。

第二层是锁机制：Agent 操作文件前先申请锁，拿到锁才能改。这需要 Harness 层面支持，实现成本较高。

第三层是后置合并：让 Agent 各自改，最后统一做 merge，冲突时人类介入。这是最灵活但也最费人的做法。

我的建议是：能用第一层就用第一层，实在不行再上第二层。第三层只适合探索性任务，不适合生产流程。

6.3 Agent 安全与权限控制

Agent 能碰什么、不能碰什么，必须有明确边界。我的做法是三层防护。

第一层是文件系统权限：Agent 运行在受限的目录下，生产配置、密钥文件、数据库迁移脚本这些目录直接不给读权限。

第二层是操作白名单：Agent 能执行的命令限定在白名单内，比如只能跑make test、go build，不能跑rm -rf、curl这类危险命令。

第三层是人工确认：涉及部署、数据变更、外部调用的操作，必须人工确认后才能执行。

这三层防护缺一不可。我见过 Agent 误删测试数据的案例，就是因为没有做文件系统权限隔离。

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

最后分享几个零散但实用的体会。

关于 Agent 的记忆：不要让 Agent 记太多。有些团队恨不得把整个项目历史都塞给 Agent，结果上下文超限，反而影响效果。我的做法是只给“当前任务相关”的上下文，历史信息按需检索。

关于 Agent 的学习曲线：前两周是最痛苦的。你会觉得 Agent 怎么这么笨，怎么老出错。但坚持两周，把 CLAUDE.md 调好、把流程跑顺，后面就是指数级的效率提升。我带的团队里，坚持下来的同学现在都回不去了。

关于工具的选择：不要频繁换工具。我见过团队三个月换了四套 Agent 框架，每次都要重新适配，效率极低。选定一套，用熟，比什么都强。

关于人的角色：AI Native 不是让人失业，是让人做更有价值的事。Agent 干了那些重复的、模式化的活，人类就能腾出精力做架构设计、业务判断、跨团队协调这些真正需要人的事。我自己的感受是，用了 Agent 之后，我写代码的时间少了，但思考的时间多了，整体产出反而更高。

关于团队推广：从一个人开始，从一个任务开始。不要一上来就搞全员培训、全流程改造。找一个痛点最明显的环节，让一个人先用 Agent 解决，跑出效果，再慢慢扩散。这是最稳的路径。

这套东西不是一蹴而就的，我自己也是摸索了大半年才跑顺。但方向是明确的：AI Native 不是要不要做的问题，是什么时候做、怎么做的问题。早动手，早受益。