AI Native团队如何用Agent重构SDLC：Plan Mode与多Agent编排实战

1. 从“人写代码”到“人管 Agent”AI Native 团队到底变了什么过去大半年我一直在带一个十来人的研发小队做 AI Native 方向的落地尝试。说实话最开始我对“AI Native 团队”这个词是有点抵触的感觉又是一个被包装出来的概念。但真正把 SDLC软件开发生命周期的每个环节都拿 Agent 重做一遍之后我发现事情确实变了——不是工具变了而是团队协作的底层逻辑变了。传统研发里人是执行主体工具是辅助。你写代码IDE 帮你补全你写文档模板帮你规范格式。但在 AI Native 范式下Agent 成了执行主体人变成了意图定义者和质量守门人。这个转变听起来简单实操起来处处是坑。我见过太多团队买了 Agent 平台、配了一堆 API Key结果还是当高级自动补全在用根本没摸到 AI Native 的门。这篇手册想解决的问题很具体一个团队从零开始怎么把 Agent 真正嵌进 SDLC 的每个环节而不是浮在表面。我会把我们在 Plan Mode、CLAUDE.md 规范、Agent 编排、并发扛压、记忆存储这几个核心环节踩过的坑和总结出的方法全部摊开讲。适合正在做 AI Native 转型的技术负责人、一线开发以及想搞清楚 Agent 到底怎么落地的人。不管你是刚接触 Agent 开发还是已经在搭企业级 Agent 平台这里应该都有你能直接抄作业的东西。2. AI Native SDLC 的整体设计与思路拆解2.1 为什么传统 SDLC 在 AI Native 团队里跑不通传统 SDLC 的核心假设是需求由人理解设计由人完成编码由人执行测试由人验证。每个环节之间的交接靠文档和会议。这套流程在纯人力团队里跑了几十年没问题。但当你把 Agent 引入之后问题立刻暴露出来。第一个问题是上下文断裂。Agent 不像人它没有“上次开会讨论过”这种隐性记忆。你让它写一个模块它不知道这个模块跟三天前另一个 Agent 写的接口有什么依赖关系。结果就是各写各的集成的时候一堆冲突。第二个问题是质量标准的模糊性。人写代码Code Review 的时候大家凭经验判断“这写得行不行”。但 Agent 需要明确的、可执行的规范。你说“代码要清晰”Agent 不知道什么叫清晰。你得告诉它函数不超过 50 行、命名用 snake_case、每个 public 方法必须有 docstring。这就是为什么 CLAUDE.md 这类规范文件在 AI Native 团队里变得极其重要。第三个问题是并发与状态管理。多个 Agent 同时干活的时候谁先谁后、谁依赖谁、中间状态存哪里这些在传统 SDLC 里根本不需要考虑因为人天然会协调。但 Agent 不会你得显式设计编排逻辑。我们最初的方案是“能自动化的就自动化”结果搞了一个月发现Agent 之间互相覆盖文件、重复劳动、甚至出现死循环调用。后来才想明白AI Native SDLC 不是把传统流程自动化而是重新设计一套以 Agent 为执行单元的流程。2.2 我们最终采用的架构三层分离 Plan Mode 驱动经过几轮迭代我们最终稳定下来的架构是三层分离意图层人负责定义目标、约束条件和验收标准。这一层的产出是结构化的任务描述不是自然语言随便写写。编排层负责把意图拆解成 Agent 可执行的任务序列管理依赖关系、并发控制和状态传递。这一层是 AI Native SDLC 的核心也是最难做的部分。执行层各个 Agent 按照编排层的指令执行具体任务比如写代码、跑测试、生成文档、做代码审查。这个架构的关键在于Plan Mode。所谓 Plan Mode就是让 Agent 在真正执行之前先输出一份完整的执行计划包括步骤拆解、依赖关系、预期产出和风险点。人审核通过之后Agent 才开始干活。为什么一定要有 Plan Mode因为我们踩过一个血坑让 Agent 直接执行一个“重构用户模块”的任务它上来就删了三个文件然后写了一堆新代码结果跟现有接口完全不兼容。如果有 Plan Mode它会先告诉你“我打算删除 A、B、C 三个文件重写 D 模块预计影响 E、F 两个调用方”你一眼就能看出问题。Plan Mode 的另一个好处是可审计。每个任务的执行计划都留档出了问题可以回溯到底是哪一步的判断错了。这在企业级 Agent 平台里是刚需。2.3 CLAUDE.mdAgent 的“员工手册”CLAUDE.md 这个文件本质上就是给 Agent 看的团队规范。它跟给人看的开发规范有什么区别区别在于精确性和可执行性。给人看的规范可以写“代码风格要统一”人自己会理解。但给 Agent 看的规范必须写成“所有变量命名使用 camelCase常量使用 UPPER_SNAKE_CASE每个函数必须有 JSDoc 注释注释语言为中文”。越具体越好最好能直接转成 lint 规则。我们的 CLAUDE.md 大概长这样# 项目规范 ## 代码风格 - 语言TypeScript strict mode - 命名变量 camelCase常量 UPPER_SNAKE_CASE类型 PascalCase - 函数不超过 50 行参数不超过 4 个超过则用对象传参 - 注释每个 export 的函数必须有 JSDoc包含 param 和 returns ## 目录结构 - src/agents/ 存放 Agent 定义 - src/tools/ 存放工具函数 - src/orchestration/ 存放编排逻辑 - tests/ 存放测试文件名与源文件对应 ## 禁止事项 - 禁止使用 any 类型 - 禁止在循环中做数据库查询 - 禁止硬编码 API Key - 禁止删除现有测试用例 ## 提交规范 - commit message 格式type(scope): description - type 可选值feat, fix, refactor, test, docs, chore这个文件放在项目根目录每次 Agent 启动时自动加载。实测下来有了这个文件之后Agent 生成的代码一次性通过 Code Review 的比例从不到 40% 提升到了 75% 以上。2.4 Agent 编排从“单打独斗”到“流水线协作”单个 Agent 的能力再强也扛不住复杂项目。真正的效率提升来自多 Agent 编排。我们的编排模型参考了流水线的思路每个 Agent 负责一个特定环节上游产出是下游输入中间通过结构化的消息传递。比如需求分析 Agent读取需求文档输出结构化的任务列表设计 Agent根据任务列表输出接口定义和数据结构编码 Agent根据设计文档生成代码测试 Agent根据代码和设计文档生成测试用例并执行审查 Agent检查代码是否符合 CLAUDE.md 规范输出审查报告每个 Agent 的输出格式都是固定的 JSON Schema这样下游 Agent 才能可靠地解析。这里有个关键点Agent 之间的通信必须结构化不能靠自然语言。我们最开始让 Agent 之间用自然语言传递信息结果下游 Agent 经常误解上游的意图错误率极高。改成 JSON Schema 之后稳定性大幅提升。3. 核心细节解析与实操要点3.1 Plan Mode 的实现细节怎么让 Agent “先想后做”Plan Mode 的核心是强制 Agent 在生成任何执行动作之前先输出一份结构化的计划。实现方式有两种第一种是提示词约束。在 System Prompt 里明确要求“在开始任何操作之前你必须先输出一个 JSON 格式的执行计划包含 steps 数组每个 step 有 action、target、reason 三个字段。只有计划被确认后才能执行。”第二种是工具调用拦截。在 Agent 框架层面拦截所有写操作文件写入、命令执行、API 调用在第一次写操作之前强制插入一个“计划确认”步骤。我们两种都用过最终采用的是第二种为主、第一种为辅的方案。因为纯提示词约束有时候会被 Agent “绕过”特别是任务比较复杂的时候它可能会忘记先输出计划。工具调用拦截是硬性的绕不过去。Plan Mode 的输出格式我们定义如下{ task_id: task-001, summary: 重构用户认证模块支持 OAuth2.0, steps: [ { step: 1, action: read, target: src/auth/, reason: 了解现有认证逻辑 }, { step: 2, action: write, target: src/auth/oauth.ts, reason: 新增 OAuth2.0 认证实现 }, { step: 3, action: modify, target: src/auth/index.ts, reason: 导出新的认证方法 } ], risks: [ 现有 session 机制可能需要同步修改, 需要更新环境变量配置 ], estimated_files_changed: 5 }人审核这个计划的时候重点看三样东西步骤是否合理、风险是否识别到位、影响范围是否可接受。如果没问题点确认Agent 才开始执行。注意Plan Mode 的计划粒度要适中。太粗了看不出问题太细了审核成本太高。我们的经验是每个 step 对应一个原子操作整个计划控制在 5 到 15 个 step 之间。3.2 Agent 记忆管理Working Memory 怎么存、存多久、怎么用Agent 的记忆问题是我们踩坑最多的领域之一。最开始我们没做记忆管理每个 Agent 都是无状态的每次调用都从零开始。结果就是同一个项目里Agent A 刚写完的接口Agent B 完全不知道又写了一个功能重复的。后来我们引入了Working Memory机制。所谓 Working Memory就是 Agent 在执行任务过程中产生的中间状态和上下文信息存在一个共享的存储里后续 Agent 可以读取。存储方案我们试过三种方案优点缺点适用场景文件系统简单直观易于调试并发写入有冲突风险小型项目Agent 数量少Redis读写快支持并发需要额外运维数据易失中型项目需要高性能PostgreSQL持久化好支持复杂查询读写相对慢大型项目需要审计和回溯最终我们选了 PostgreSQL 为主、文件系统为辅的方案。PostgreSQL 存结构化的任务状态和 Agent 产出文件系统存大块的代码和文档内容。Working Memory 的数据结构大概是这样CREATE TABLE agent_memory ( id SERIAL PRIMARY KEY, task_id VARCHAR(64) NOT NULL, agent_id VARCHAR(64) NOT NULL, memory_type VARCHAR(32) NOT NULL, -- context, output, decision content JSONB NOT NULL, created_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP );关键设计点每条记忆都有过期时间。不是所有记忆都需要永久保留。比如“当前正在处理的文件内容”这种上下文任务完成后就可以清理。“架构决策记录”这种则需要长期保留。我们默认的过期策略是上下文类记忆 24 小时过期产出类记忆 7 天过期决策类记忆永久保留。实操心得Working Memory 的读取要有优先级。Agent 启动时先加载任务相关的决策记忆再加载最近的产出记忆最后按需加载上下文记忆。不要一次性把所有记忆都塞给 Agent会撑爆上下文窗口。3.3 Agent 并发扛压怎么让多个 Agent 同时干活不打架并发是 AI Native 团队必须面对的问题。当你有 10 个 Agent 同时在一个代码库上干活的时候冲突是必然的。我们的解决方案是基于文件锁的任务分区。具体来说每个 Agent 在执行写操作之前必须先申请目标文件的锁锁的粒度是文件级别不是目录级别目录级别太粗会导致大量等待如果文件已被锁定Agent 进入等待队列或者被编排层重新分配到其他任务锁有超时机制默认 5 分钟防止死锁这套机制用 Redis 实现核心代码如下import redis import time r redis.Redis(hostlocalhost, port6379) def acquire_lock(file_path, agent_id, timeout300): lock_key flock:{file_path} # SET NX 保证原子性 acquired r.set(lock_key, agent_id, nxTrue, extimeout) if acquired: return True # 检查是否是自己的锁可重入 current_holder r.get(lock_key) if current_holder and current_holder.decode() agent_id: r.expire(lock_key, timeout) return True return False def release_lock(file_path, agent_id): lock_key flock:{file_path} current_holder r.get(lock_key) if current_holder and current_holder.decode() agent_id: r.delete(lock_key)除了文件锁我们还做了任务级别的并发控制。编排层维护一个任务队列每个任务有依赖关系图。只有当所有前置任务完成后当前任务才能被分配给 Agent。这样避免了 Agent 在依赖未就绪的情况下盲目开工。实测数据在没有并发控制之前10 个 Agent 同时干活冲突率大概在 30% 左右即 30% 的文件写入操作会因为冲突而失败重试。引入文件锁和任务依赖控制之后冲突率降到了 3% 以下。3.4 Agent 安全别让 Agent 把你的数据库删了Agent 安全是个容易被忽视但极其重要的问题。我听过最离谱的案例是一个团队让 Agent 自动执行数据库迁移脚本结果 Agent 理解错了执行了 DROP TABLE。我们的安全策略分三层第一层权限隔离。Agent 运行在独立的容器里只有项目目录的读写权限没有系统级权限。数据库操作走专门的 API不直接连数据库。第二层危险操作拦截。维护一个危险操作清单包括DROP、DELETE、TRUNCATE、rm -rf、format等关键词。Agent 的输出如果包含这些操作必须经过人工确认才能执行。第三层沙盒执行。所有代码执行都在沙盒里进行沙盒有资源限制CPU、内存、网络即使 Agent 写了恶意代码也影响不到宿主机。# docker-compose.yml 中 Agent 容器的安全配置 services: agent-worker: image: agent-worker:latest read_only: true tmpfs: - /tmp:size100M security_opt: - no-new-privileges:true cap_drop: - ALL mem_limit: 2g cpus: 2.0 networks: - agent-internal注意read_only: true会让容器文件系统只读Agent 需要写入的目录通过 volume 挂载。这样即使 Agent 被恶意输入操控也无法修改系统文件。4. 实操过程与核心环节实现4.1 从零搭建一个 AI Native 开发环境假设你现在要从零开始搭建一套 AI Native 开发环境下面是我建议的步骤。第一步确定技术栈。我们的选择是Agent 框架LangGraph编排能力强支持状态图模型Claude 3.5 Sonnet代码能力强长上下文稳定存储PostgreSQL Redis容器Docker Docker Compose代码托管GitAgent 操作 Git 仓库不直接改文件系统第二步搭建基础目录结构。ai-native-project/ ├── CLAUDE.md # Agent 规范文件 ├── docker-compose.yml # 容器编排 ├── src/ │ ├── agents/ # Agent 定义 │ │ ├── planner.py # 计划 Agent │ │ ├── coder.py # 编码 Agent │ │ ├── tester.py # 测试 Agent │ │ └── reviewer.py # 审查 Agent │ ├── orchestration/ # 编排逻辑 │ │ ├── graph.py # 任务依赖图 │ │ └── scheduler.py # 调度器 │ ├── tools/ # 工具函数 │ │ ├── file_ops.py # 文件操作 │ │ ├── git_ops.py # Git 操作 │ │ └── db_ops.py # 数据库操作 │ └── memory/ # 记忆管理 │ └── working_memory.py ├── tests/ # 测试 └── workspace/ # Agent 工作目录挂载到容器第三步配置 Agent 的 System Prompt。每个 Agent 的 System Prompt 都要包含角色定义、能力边界、输出格式要求、CLAUDE.md 规范内容。以编码 Agent 为例CODER_SYSTEM_PROMPT 你是一个资深 TypeScript 开发工程师负责根据设计文档生成代码。 ## 你的能力 - 阅读设计文档和现有代码 - 生成符合项目规范的 TypeScript 代码 - 编写单元测试 ## 你的限制 - 不能修改 CLAUDE.md - 不能删除现有测试用例 - 不能执行数据库迁移 - 遇到不确定的情况必须输出问题而不是猜测 ## 输出格式 你的输出必须是 JSON 格式 { files: [ {path: src/xxx.ts, content: ...} ], tests: [ {path: tests/xxx.test.ts, content: ...} ], notes: 需要人工确认的问题 } ## 项目规范 {CLAUDE_MD_CONTENT} 第四步实现编排图。用 LangGraph 定义任务流转from langgraph.graph import StateGraph, END def create_workflow(): workflow StateGraph(AgentState) workflow.add_node(plan, plan_node) workflow.add_node(human_review, human_review_node) workflow.add_node(code, code_node) workflow.add_node(test, test_node) workflow.add_node(review, review_node) workflow.set_entry_point(plan) workflow.add_edge(plan, human_review) workflow.add_conditional_edges( human_review, should_proceed, {approved: code, rejected: plan} ) workflow.add_edge(code, test) workflow.add_edge(test, review) workflow.add_conditional_edges( review, review_result, {pass: END, fail: code} ) return workflow.compile()这个图定义了完整的开发流程计划 → 人工审核 → 编码 → 测试 → 审查 → 通过或打回。4.2 一个完整任务的执行记录让我用一个真实的任务来展示整个流程。任务是“给用户模块添加邮箱验证功能”。阶段一Plan Mode计划 Agent 输出的执行计划{ task_id: task-042, summary: 添加邮箱验证功能, steps: [ {step: 1, action: read, target: src/user/, reason: 了解现有用户模块结构}, {step: 2, action: read, target: src/email/, reason: 了解现有邮件发送能力}, {step: 3, action: write, target: src/user/email_verification.ts, reason: 实现邮箱验证逻辑}, {step: 4, action: modify, target: src/user/index.ts, reason: 导出验证方法}, {step: 5, action: write, target: tests/user/email_verification.test.ts, reason: 编写测试}, {step: 6, action: modify, target: src/db/migrations/, reason: 添加验证码存储表} ], risks: [ 需要新增数据库表需确认迁移策略, 邮件发送频率需要限流防止滥用 ], estimated_files_changed: 6 }人工审核我看了之后在风险里补充了一条“验证码有效期需要可配置”然后批准。阶段二编码编码 Agent 根据计划生成代码。关键产出// src/user/email_verification.ts import { randomBytes } from crypto; import { db } from ../db; import { sendEmail } from ../email; const CODE_EXPIRY_MINUTES parseInt(process.env.VERIFICATION_CODE_EXPIRY || 15, 10); export async function sendVerificationCode(email: string): Promisevoid { const code randomBytes(3).toString(hex).toUpperCase(); const expiresAt new Date(Date.now() CODE_EXPIRY_MINUTES * 60 * 1000); await db.query( INSERT INTO verification_codes (email, code, expires_at) VALUES ($1, $2, $3), [email, code, expiresAt] ); await sendEmail({ to: email, subject: 邮箱验证码, body: 您的验证码是${code}${CODE_EXPIRY_MINUTES} 分钟内有效。 }); } export async function verifyCode(email: string, code: string): Promiseboolean { const result await db.query( SELECT code, expires_at FROM verification_codes WHERE email $1 AND used false ORDER BY created_at DESC LIMIT 1, [email] ); if (result.rows.length 0) return false; const record result.rows[0]; if (new Date(record.expires_at) new Date()) return false; if (record.code ! code) return false; await db.query(UPDATE verification_codes SET used true WHERE email $1 AND code $2, [email, code]); return true; }阶段三测试测试 Agent 生成测试用例并执行。这里有个细节测试 Agent 会先检查现有测试的写法保持风格一致。// tests/user/email_verification.test.ts import { sendVerificationCode, verifyCode } from ../../src/user/email_verification; import { db } from ../../src/db; import { sendEmail } from ../../src/email; jest.mock(../../src/db); jest.mock(../../src/email); describe(邮箱验证, () { beforeEach(() { jest.clearAllMocks(); }); it(发送验证码应该写入数据库并发送邮件, async () { (db.query as jest.Mock).mockResolvedValue({ rows: [] }); (sendEmail as jest.Mock).mockResolvedValue(undefined); await sendVerificationCode(testexample.com); expect(db.query).toHaveBeenCalledWith( expect.stringContaining(INSERT INTO verification_codes), expect.arrayContaining([testexample.com]) ); expect(sendEmail).toHaveBeenCalled(); }); it(验证码过期应该返回 false, async () { const expiredDate new Date(Date.now() - 1000); (db.query as jest.Mock).mockResolvedValue({ rows: [{ code: ABC123, expires_at: expiredDate }] }); const result await verifyCode(testexample.com, ABC123); expect(result).toBe(false); }); });测试执行结果5 个测试用例4 个通过1 个失败。失败的用例是“验证码错误应该返回 false”原因是 mock 数据没有正确设置。测试 Agent 自动修复了 mock 数据重新执行后全部通过。阶段四审查审查 Agent 检查代码是否符合 CLAUDE.md 规范。审查报告{ task_id: task-042, result: pass, issues: [ { severity: minor, file: src/user/email_verification.ts, line: 8, message: 建议将 CODE_EXPIRY_MINUTES 的默认值提取到配置文件中 } ], stats: { files_reviewed: 3, lines_added: 87, test_coverage: 92% } }审查通过任务完成。整个流程从计划到完成耗时约 12 分钟其中人工审核占了 3 分钟。4.3 参数选择与计算过程在搭建过程中有几个关键参数需要根据实际情况计算。并发 Agent 数量。这个取决于两个因素API 速率限制和任务依赖度。我们的经验公式是最大并发数 min(API_RPM / 每任务平均请求数, 可并行任务数)比如 API 限制是每分钟 100 次请求每个任务平均需要 20 次请求那么最大并发是 5 个 Agent。如果任务依赖度高很多任务需要串行实际并发数还要更低。Working Memory 大小。每条记忆的平均大小约 2KB一个中型项目约 50 个任务产生的记忆总量约 100MB。PostgreSQL 完全扛得住。但如果项目很大需要考虑分区存储。锁超时时间。这个要根据任务的平均执行时间来定。我们的经验是锁超时 任务平均执行时间 × 3比如编码任务平均需要 2 分钟锁超时设为 6 分钟。太短了会导致任务被误判为死锁太长了会拖慢整体进度。5. 常见问题与排查技巧实录5.1 Agent 执行报错“execution terminated due to error”怎么排查这是最常见的问题之一。Agent 执行到一半突然报错终止日志里只有一句“execution terminated due to error”。排查思路如下第一步看上下文长度。最常见的原因是上下文窗口超了。Agent 在处理大文件或者长对话时很容易把上下文撑爆。检查方法看报错前的最后一次请求的 token 数。如果接近模型上限就是这个问题。解决方案拆分任务或者引入上下文压缩机制。第二步看工具调用。Agent 调用的某个工具返回了错误导致整个执行链断了。检查方法看报错前的最后一次工具调用返回了什么。常见错误包括文件不存在、权限不足、API 超时。第三步看模型输出格式。Agent 输出的 JSON 格式不对解析失败。这种情况通常会在日志里看到“JSON parse error”之类的信息。解决方案在 System Prompt 里强化格式要求或者引入输出校验和重试机制。我们整理了一个排查速查表报错特征可能原因排查方法解决方案上下文超限任务太大看 token 数拆分任务压缩上下文工具调用失败权限/路径/网络看工具返回修复工具配置加重试JSON 解析失败输出格式不对看原始输出强化格式约束加校验超时任务太复杂看执行时间增加超时拆分任务死循环依赖关系错误看调用链修复依赖图加最大步数限制5.2 Agent 之间“打架”怎么办多 Agent 协作时最常见的问题是重复劳动和互相覆盖。重复劳动的典型场景Agent A 和 Agent B 同时被分配了“写用户模块”的任务因为编排层没有正确识别任务依赖。解决方案在任务分配之前先做一次任务去重检查。具体做法是维护一个“已分配任务”的集合新任务分配前先检查是否与已有任务重叠。互相覆盖的典型场景Agent A 修改了src/user/index.tsAgent B 也修改了同一个文件后写的覆盖了先写的。解决方案就是我们前面说的文件锁机制。但文件锁只能防止同时写不能防止逻辑冲突。比如 Agent A 删了一个函数Agent B 还在调用它。这种需要语义级别的冲突检测目前我们靠人工审核 Plan Mode 来兜底。实操心得多 Agent 协作时任务粒度宁小勿大。一个 Agent 只做一件事做完就释放资源。这样冲突概率最低出问题也容易定位。5.3 Agent 生成的代码质量不稳定怎么破这个问题困扰了我们很久。同一个 Agent同样的提示词有时候生成的代码很好有时候一塌糊涂。后来发现原因主要有三个原因一上下文污染。Agent 在处理任务时如果上下文中混入了不相关的信息比如之前任务的残留记忆生成质量会下降。解决方案每个任务开始时清理 Working Memory 中与当前任务无关的内容。原因二规范文件太长。CLAUDE.md 如果写得太长超过 2000 字Agent 会“记不住”后面的内容。解决方案把规范拆成核心规范和扩展规范核心规范每次加载扩展规范按需加载。原因三模型温度参数。温度太高比如 0.8会导致输出随机性大温度太低比如 0.1会导致输出过于保守。我们的经验值是0.3 到 0.5之间代码生成用 0.3文档生成用 0.5。5.4 Agent 安全审计怎么做安全审计的目的是确保 Agent 的行为可追溯、可解释、可控制。我们做了三件事第一全量日志。Agent 的每一次输入输出、每一次工具调用、每一次决策都记录到日志系统。日志保留 90 天。第二决策回溯。每个任务完成后生成一份决策报告说明“为什么这么做”。比如“选择用 Redis 而不是 PostgreSQL 存锁因为需要高性能的 SET NX 操作”。第三异常告警。监控 Agent 的行为发现异常立即告警。异常包括短时间内大量文件删除、访问敏感路径、调用未授权的 API。# 异常检测示例 def check_anomaly(agent_id, action, target): # 检测大量删除 if action delete: recent_deletes count_recent_actions(agent_id, delete, window60) if recent_deletes 10: alert(fAgent {agent_id} 在 1 分钟内删除了 {recent_deletes} 个文件) # 检测敏感路径访问 sensitive_paths [/etc/, /root/, .env, credentials] if any(p in target for p in sensitive_paths): alert(fAgent {agent_id} 尝试访问敏感路径 {target})5.5 团队协作中的常见摩擦与解决AI Native 团队不只是技术问题还有人的问题。我们遇到过的摩擦包括摩擦一开发人员不信任 Agent 的代码。这是最开始的普遍心态。解决方案让开发人员参与 Plan Mode 的审核他们发现 Agent 的计划确实合理之后信任感会逐渐建立。摩擦二Agent 和人的工作边界模糊。谁负责什么一开始没定义清楚。解决方案明确划分——人负责需求定义、架构设计、Plan Mode 审核、最终验收Agent 负责编码、测试、文档、初步审查。摩擦三出问题了互相甩锅。Agent 写错了代码开发说“是 Agent 的问题”Agent 的维护者说“是提示词没写好”。解决方案建立责任追溯机制。每个任务都有完整的执行记录问题出在哪个环节一目了然。如果是提示词问题改提示词如果是审核没到位改审核流程。6. 一些踩坑之后的个人体会这套 AI Native 开发流程跑了大半年最大的体会是Agent 不是银弹它放大了团队的能力也放大了团队的问题。如果团队的规范不清晰、流程不严谨引入 Agent 之后只会更乱。反过来如果团队本身工程素养好Agent 能把效率提升好几倍。另一个体会是Plan Mode 是整个流程的灵魂。没有 Plan ModeAgent 就是一个高级自动补全有了 Plan ModeAgent 才真正成为一个可管理的执行单元。我建议任何想落地 AI Native 的团队都从 Plan Mode 开始做起先把“先想后做”这个习惯建立起来。最后分享一个我们最近在试的小技巧让 Agent 自己写 CLAUDE.md。具体做法是让 Agent 分析现有代码库的风格和规范自动生成一份 CLAUDE.md 草稿然后人工审核修改。实测下来Agent 写的草稿能覆盖 80% 的规范点人工只需要补充一些业务特定的约束。这个技巧特别适合那些没有成文规范的老项目能快速把隐性规范显性化。