不少开发者日常使用 AI 编程助手时，会陷入这样一种状态：

在 IDE 里敲下一行提示词，屏住呼吸等待几十秒，看到代码刷出来，顺手点击接受；本地一运行，控制台红了一片；于是把报错日志复制回对话框，再等几十秒……循环往复。

你确实换了更新的工具，打字与生成速度也变快了，但如果退后一步看整体交付周期：从需求提出、系统设计、代码编写、反复调试到上线发布，整体交付往往并没有带来预期的显著提速。开发者依然容易陷入疲态，核心原因在于许多人仍把自己放在 AI 与终端之间，充当实时的人肉路由器、异常传递员和点击确认器。

2025 年 9 月，Kiro 团队发布了由 Clare Liguori 主笔的工程专题《Frontier Engineering》（前沿工程学），系统梳理了 10 条面向多代理（Agent）研发实践的探索性原则。

作者的核心主张在于：当前的软件研发实践正在出现分化。一部分团队只是在既有流程中换了编码工具，而前沿探索者则在尝试重构工作方式——从亲自手写每一行代码，转向搭建让 Agent 自主闭环推进的工程基础设施，以追求显著乃至阶跃式的交付提速。

如果你已经熟悉 AI 辅助编程，却发现端到端交付依旧频繁受阻于人肉卡点，本文将结合 Kiro 的 10 条原则，解析这套工作流背后的运行机制、依赖条件与工程边界。

10 条原则阅读地图

1. Architect, not typist → 角色重置
2. Maximize agent time → 摆脱人肉卡点
3. Build for agents → 改造代码库
4. Build a fast feedback loop → 快速反馈闭环
5. Direction over execution → 角色重置中的方向与规格驱动
6. Treat code as disposable → 代码可重写，边界测试是契约
7. Hold the line on human standards → 人类标准与审查分工
8. Trust the boundaries → 防护栏工程
9. Use agents for everything → 全流程协同
10. Constantly tune your setup → 持续调优的飞轮

角色重置：从敲击代码的打字员，转向定义意图的架构师

在前沿工程实践中，Kiro 观察到走在最前面的开发者手写的生产代码占比已经降至 1% 以下。需要强调的是，这是作者在特定实践中观察到的现象，而非要求所有团队生搬硬套的目标 KPI。这并不意味着开发者的职责变轻了，而是工程重心发生了显著转移。

图：Kiro「Architect, not typist」原则配图，示意工程师把重心转向系统方向与验证。

以往大部分时间消耗在敲击键盘、寻找语法细节与排查低级 API 调用上。但在由 Agent 承接具体编码的模式下，软件研发的核心成本转变为两件事：第一，清晰定义什么叫「Done」（需求边界、约束、验收准则）；第二，验证输出物是否真正符合系统意图。

很多开发者使用 Agent 效果不佳，第一步往往踩在「意图模糊」的陷阱上（注：以下加鉴权对比为本文为了说明意图表达机制而展开的示意，非 Kiro 原文用例）：

• 低效意图：“给这个 API 加上用户鉴权。”
  面对这句指令，Agent 往往自行脑补技术选型、随意决定拦截范围与默认错误响应格式。一旦其假设与业务实际冲突，开发者就需要耗费额外精力推倒重来。
  
• 合格意图：“为以下端点增加基于角色的访问控制（RBAC）：/admin/* 仅限 Admin 角色，/api/v1/user/* 允许 User 与 Admin 角色访问。当 Token 过期时，按照规范返回 401 状态码及 TOKEN_EXPIRED 错误体；提供针对未授权访问、令牌过期、伪造签名的测试用例，并确保全部通过。”

在这里，具体代码执行的边际成本大幅下降，而定义系统方向（Direction）的权重被显著放大。

系统架构、API 契约、外部依赖选择以及核心权衡（Trade-offs）一旦偏离，推倒修正的成本依然不低。因此，开发者应当把精力聚焦在系统的关键骨架上。在设计阶段，也可以让 Agent 成为方案推演的助手：例如让它调研多种可行的技术路线并编写可对比的原型，通过原型运行结果与实际证据来辅助团队做决策。

方向确定后，工作应当转入规格驱动开发（spec-driven development）：先与 Agent 共同写清规格与需求，以减少生成代码之前的歧义；在推进过程中持续判断架构能否承受真实负载、既有权衡是否需要重审，以及产品是否已经达到可以交给用户的状态。

图：Kiro「Direction over execution」原则配图，示意先确定方向与规格，再扩大执行。

摆脱人肉卡点：把「60 秒等待循环」拉长为「30 分钟自愈闭环」

要实现开发吞吐量的跃迁，必须打破「人在回路中（Human-in-the-loop）」的紧耦合。

如果你坐在屏幕前，每次发完指令就盯着光标闪烁，等待 60 秒后手动帮它测、手动喂报错，那么你就是整个流水线上最大的并发瓶颈。

前沿开发者的做法是给 Agent 分配具备明确验证标准、生命周期更长的任务。例如 Kiro 在原则中给出的典型任务指令为：

“实现功能、编写测试、运行测试并确保全部通过，且新代码测试覆盖率达到 90%。”（注：此为 Kiro 官方的任务示例，用于展现将实现与校验打包交付的闭环模式，而非对所有项目的硬性 KPI）

在这个过程中，Agent 初次写出的代码存在缺陷十分常见。关键在于：不要替它去排查语法错和环境错，让它在受控环境中自行运行、捕获错误输出并自我修正，直到收敛出符合预期的结果。

两种工作模式的差别：

• 低效的人肉轮询：人发 Prompt → 等待约 60 秒 → Agent 生成代码 → 人手动测试和看日志 → 人复制报错回去 → 再次等待。人的注意力和切换成本决定了吞吐上限。
• 长程自愈闭环：人先定义目标、验证脚本与验收指标，Agent 再持续运行 30 分钟或更长时间：
  1. 编写实现与测试；
  2. 执行本地验证；
  3. 未通过时捕获错误并修复，返回上一步；
  4. 全部通过后提交 Diff，等待人异步审查。

当单个 Agent 能在 30 分钟甚至更长时间内自主闭环时，开发组织模式也随之升级：开发者可以并发调度多个面向独立任务的 Agent，或者将长任务置于后台运行，后续再统一进行异步审查（Async Review）。

但 Kiro 在专题中特别强调了注意力管理（Attention Management）：这绝不意味着盲目追求并发 Agent 的数量。核心在于只让那些拥有清晰目标与可靠验证闭环的任务持续运行，并在整个过程中严格维持质量标准；同时开发者需要建立清晰的注意力预算与生活边界，克制在晚餐时或深夜反复查岗看进度的冲动。

图：Kiro「Maximize agent time」原则配图，示意从短轮询转向带验证的长程任务。

改造代码库：像对待「每次都在重新入职的新员工」一样准备环境

人类团队成员入职，往往只需要通读一次文档、配好一次本地环境，相关的业务背景和工程默契就会长期储存在大脑中。

但 Agent 不一样：每一个全新的会话（Session），都像一位不了解当前业务的新协作者在「第一天入职」。

如果代码库全靠口口相传的默契运行，Agent 就会反复在缺乏上下文的地方受阻。要让 Agent 高效工作，仓库必须建立起面向代理的基础设施：

图：Kiro「Build for agents」原则配图，强调文档、边界、测试与工具对 Agent 的支撑。

1. 仓库级基础支撑与工程卫生

• 完备的 README 与架构文档：提供清晰的系统全貌、技术栈选型与目录指引，让新会话能迅速建立系统级认知。
• 描述预期行为的测试套件：编写能清晰反映业务预期行为的测试，为 Agent 提供自验证的直接依据。
• 清晰的模块边界与强类型：通过严谨的模块解耦与强类型约束，减少隐式依赖；含混的类型往往会显著增加 Agent 推理歧义的概率。
• 快速构建与高信息量报错：确保本地构建与测试反馈足够快，且编译器和测试报错包含具体、可定位的线索。
• 遗留大型仓库的应对策略：对于历史包袱重的大型代码库，不要指望一蹴而就，而应采取逐模块改造的方式，并在任务中收窄 Agent 的上下文与操作范围（Scope）。

2. 显性化的工程规则与工具集成

• 引导文件（Steering Files）：将团队的代码规范、目录约定与常用规则提炼成规则文件，提供持续适用的工程约定与编码标准。
• 按需技能（Skills / Procedures）：将复杂流程（如数据库迁移、API 发布）封装为模块化步骤，仅在特定任务触发时动态载入，避免无关信息挤占上下文。
• 环境脚本与 CLI/MCP 工具：提供可脚本化拉起的本地环境，并通过 CLI 或 MCP（Model Context Protocol）工具让 Agent 能自主查询日志、拉取 Schema 或调用辅助服务。

3. 持久化关键决策与上下文约束

在任务推进过程中，要求 Agent 记录设计决策（例如使用 ADR）并在核心链路补充关键上下文与约束注释。这并非要求把冗长的模型思考过程原样堆进代码库，而是将必要的设计决策、背景假设与限制条件持久化，为后续会话及其他协作者提供连续的工程记忆。

快速反馈闭环：从本地校验工具到基于属性的测试补充

Agent 能够自主定位并修复问题的基础，在于拥有一套敏捷、本地化、自动化的反馈工具链。

图：Kiro「Build a fast feedback loop」原则配图，示意让 Agent 快速看到运行与测试结果。

如果 Agent 每次调整界面，都必须依赖人类打开浏览器人工核对；或者修改接口必须部署到远端测试服才能验证，自愈反馈就会被打断，人类也会重新被卷入繁琐的实时确认中。

在前沿实践中，快速反馈通常依赖以下本地能力：

1. 静态代码检查器（Linter）与单元测试（Unit Tests）：快速发现语法、代码风格与基础逻辑偏差。
2. 可渲染并视觉验证界面的浏览器（Browser）：供 Agent 自主加载前端页面，进行 DOM 结构与界面呈现的视觉比对校验。
3. 本地轻量级依赖与模拟（Local Mocks）：通过本地 Mock 或容器化手段，支持脱离外部公共环境在本机拉起全栈端到端测试（E2E）。

而在各类测试手段中，基于属性的测试（Property-based Testing） 是一种尤其有价值的补充，尽管它并非必须引入的门槛，也不能直接替代基础的单元测试。

传统的示例型单元测试通常针对特定输入断言固定输出。当 Agent 自行编写测试覆盖自身代码时，容易陷入与实现逻辑相同的思维惯性。而基于属性的测试则要求声明系统在广泛输入下必须满足的不变量（Invariants）（注：以下示例为本文为了说明机制而展开的示意，非 Kiro 原文用例）：

• 序列化不变量：“对任意满足约束的对象，serialize 后再 deserialize，与原对象在规定语义上等价。”
• 资金划转不变量：“在不考虑手续费、汇率换算与舍入误差的前提下，两账户余额变化量之和恒等于 0。”

借助属性测试在随机生成的广泛输入样本中检验边界，Agent 能更容易暴露隐藏在常规测试之外的边缘异常，进而针对失败用例做进一步的代码调整。

代码可重写，边界测试是契约

在传统研发流程中，推倒重写往往伴随着高昂的时间成本与心理阻力。

但随着代码生成与重写成本的实质性下降，当既有实现或架构方向被证实并不理想时，果断舍弃错误方向、重新生成实现变得更加可行。 这并不意味着所有工程成本归零，而是团队不再需要为了挽救别扭的局部实现而承担长期的技术债。

图：Kiro「Code is disposable」原则配图；可替换的是实现，重写仍需边界测试保护。

这里需要区分两层：

• 可替换层（Disposable Layer）：具体的内部实现逻辑与局部私有函数。方向不佳时，可以让 Agent 重新起草。
• 契约保护层（Contract Layer）：端到端集成测试、基于属性的测试、负载与性能基线测试。它们描述外部行为与系统边界，是重写过程中应当保留的验收标准。

在这类重写中，应当被重点保留并作为重构基石的，是边界测试（Boundary Tests）：

• 覆盖外部预期行为的端到端测试（E2E Tests）；
• 检验核心规则与不变量的属性测试（Property-based Tests）；
• 验证高并发与极限表现的负载测试（Load Tests）。

这三类外围测试构成了系统对外承诺的重写契约（Contract）。内部私有函数或过度耦合的单元测试可以随着旧代码一同更替；只要高层的边界契约清晰有效，Agent 就能在明确的约束范围内探索不同的实现路线，逐步收敛出符合系统预期的代码。架构设计与 API 取舍仍是昂贵、需要审慎判断的方向性决策，但当事实证明原方向有误时，它们也需要被重新审视。

防护栏工程：构建最小权限边界与分层防护

给予 Agent 充分的自主运行空间，并不意味着可以不做安全控制。

图：Kiro「Trust the boundaries」原则配图，示意以最小权限与防护栏约束自主执行。

许多团队在引入 Agent 时容易出现两种偏差：一种是过度设防，几乎对所有只读或本地命令都设置弹窗审批，很快导致人类产生严重的「审批疲劳」并失去辨识力；另一种则是防护缺位，随意赋予全盘读写或敏感凭证，带来不可逆的操作风险。

Kiro 在安全原则中给出的核心策略是：按当前任务的最小必要范围限制文件、工具、网络与凭证访问，在此前提下让 Agent 无人盯守运行（run unattended）。

实施时通常遵循“从窄开始、逐步放宽”的路径，并建立分层防护：

• 权限与工具边界
  需避免：默认赋予全系统或全工具读写权限。
  防护栏：从较窄的必要工具集开始，根据任务逐步放宽，仅在确有需要时挂载对应能力。
• 操作审批设卡
  需避免：无论操作轻重频繁弹窗，或完全不设审批。
  防护栏：允许只读操作和受控的本地测试自主执行，仅对真正具有不可逆影响的高危动作设卡审批，例如破坏性数据变更或外部生产发布。
• 凭证与生产授权
  需避免：将高权限凭证混入全局环境变量。
  防护栏：生产权限与凭证默认严格不授予；日常使用模拟数据或有限沙箱凭证，只有在经过明确、审慎的授权时才可开放特定权限。
• 安全与代码防护
  需避免：仅靠合并前的人工肉眼扫视。
  防护栏：结合自动化静态分析（SAST）、自动化推理或形式化分析类工具、敏感信息扫描等能力，构建分层的安全防护网。

这种边界设计的目标，是在保障系统与数据安全的前提下，让 Agent 在受控范围内顺畅推进，最大程度降低因频繁打断而带来的流程停滞。

人类标准的坚守与审查层级分工

不论代码是由人类手敲还是由 Agent 生成，最终合入主干并投入运行，工程责任始终由人类工程师承担。

图：Kiro「Hold the line on human standards」原则配图，强调生成代码仍需满足同一质量标准。

随着生成代码量的增加，团队不能因追求吞吐而稀释质量标准。但在高频输出面前，完全依靠人类逐行做最初步的机械审查往往难以维系。Kiro 提出的审查演进路径包含明确的前提与分工：

1. 初期人工逐行校准：在团队引入 Agent 的初期阶段，工程师需要坚持逐行阅读审查生成代码，以准确摸清所使用模型的长处、编码偏好与常见失败模式，建立基础的校准判断。
2. AI Reviewer 承担前序检查：随着对模型特性的掌握，可以在本地提 PR 前和 CI 流程中引入专门的 AI Reviewer，负责自动化检查代码正确性、安全性、可维护性、测试质量与典型 Bug 模式，逐步承担起前几轮反馈的工作。
3. 人类聚焦核心架构与系统影响：人类工程师将注意力聚焦在更关键的高阶判断上：
   • 整体架构与模块职责划分是否合理？
   • 变动对上下游依赖会产生怎样的连锁影响？
   • 安全边界与业务权限是否严密？
   • 改动是否真正契合系统长期意图？
4. 部署后验证与回归监控：Agent 的闭环并不仅停留在提交 PR。还可将其延伸到部署阶段——让 Agent 参与部署监测、验证生产环境运行行为，并在出现指标回归或异常时协助启动排查与修复流程。

全流程协同：Agent 不只是写代码的工具

在多代理实践中，另一个常见的误区是将 Agent 狭隘地等同于“写代码的打字机”。Kiro 的第 9 条原则明确指出：Agent 的能力应当贯穿软件研发与运维的全生命周期。

图：Kiro「Use agents for everything」原则配图，示意 Agent 的适用范围超出代码生成。

除了编写和重构业务代码，Agent 还可以广泛应用于：

• 方案与设计文档：起草架构方案草案、接口设计说明与技术调研报告。
• 运营与故障调查：在排障与事件响应中聚合错误日志、定位调用链路异常。
• 项目与运维协同：生成状态更新、Sprint 总结报告、On-call 轮值交接与日常工程文档维护。

这类任务遵循统一的协作流程：提供上下文（Context）→ 明确预期结果（Outcome）→ 由 Agent 起草初稿 → 由人工审阅并修订后再对外分享。

更进一步，在规划、开发、测试、部署到日常运维的不同环节中，负责各类任务的 Agent 应当尽可能共享工程上下文、Steering 引导规则与底层工具（CLI/MCP），从而在整个研发生命周期内形成连贯的协作合力。

建立持续调优的飞轮系统

前沿工程学绝非一劳永逸的配置，而是一种演进式的工程实践。

图：Kiro「Constantly tune your setup」原则配图，示意通过根因分析持续改进规则与工具。

在日常开发中，每一次 Agent 遇到阻碍、执行跑偏或者产生不必要的打断时，不应简单归咎于模型能力，也不应盲目把所有问题都一律归为环境缺陷。前沿实践的做法是：对反复出现的错误或打断进行深入的根因分析，判断其症结究竟在于业务约束不清、工具缺失还是权限过于严格，进而将其沉淀为对 Agent Setup 的具体改进：

• 经常混淆两个相似工具的用法？→ 在 Steering 规则文件中补上明确的使用场景与正反例说明。
• 复杂的操作流程反复失误？→ 将该流程提炼固化为一个独立的 Skill 脚本。
• 缺乏必要的环境上下文数据？→ 编写轻量级 CLI 工具或通过 MCP Server 提供信息获取通道。
• 在安全的本地操作上频繁打断等待人工放行？→ 根据根因审慎调整执行环境的权限配置。

这条飞轮可以压缩为四步：

1. Agent 执行长程任务；
2. 记录反复报错、不必要打断与其他阻碍；
3. 由人做根因分析，区分业务约束、流程、工具与权限问题；
4. 更新相应的 Steering、Skill、CLI/MCP 或权限边界，再让下一轮任务验证改进是否有效。

随着这种根因分析与调优的积累，工程环境对 Agent 的支撑会愈发稳健。更重要的是：底层基础模型总是在持续演进。 新模型发布后，应重新评估那些为了弥补旧模型弱点而设置的 workaround；只有经验证不再必要的规则或提示词才清理。而围绕代码库沉淀下来的清晰契约、自动化测试套件、受控权限边界与 MCP 工具链，能够继续复用并帮助新模型更稳定地发挥作用。

开发者落地自查清单

如果你打算从今天开始改造自己的开发流，可以对照以下维度逐步推进：

• 手写比例
  传统警讯：大部分常规代码与样板代码仍靠人工逐行编写。
  实践方向：聚焦定义系统意图、架构契约与验收边界。Kiro 观察到前沿开发者手写生产代码可降至 1% 以下。
• 交互与注意力
  传统警讯：陷入频繁的人肉盯梢与 60 秒轮询，随时被打断。
  实践方向：交付具有自验证闭环的长程任务，异步审查，并维持注意力预算与非工作时间边界。
• 验证与测试
  传统警讯：依赖人工肉眼检查，或仅有与局部实现紧绑定的单元测试。
  实践方向：依托本地自动化验证闭环，将端到端测试与属性测试作为重构保护契约。
• 代码库上下文
  传统警讯：依赖团队口口相传与默契，文档与规范缺失。
  实践方向：完备 README 与架构文档，沉淀 Steering 规则文件、按需 Skills 与轻量 CLI/MCP 工具。
• 重构观念
  传统警讯：舍不得废弃旧代码，被历史沉没成本绑架。
  实践方向：在边界测试保护下，借力代码重写成本下降，舍弃方向偏差的局部实现。
• 权限与安全
  传统警讯：频繁弹窗审批导致疲劳，或无防护全盘开放。
  实践方向：遵循最小必要权限，从窄开始逐步放宽，仅对不可逆动作设卡，生产权限默认不开放。
• 错误归因
  传统警讯：情绪化指责模型，或将所有报错盲目归为环境问题。
  实践方向：先对反复错误或不必要打断做根因分析，确认属于规则、工具或权限缺陷后再沉淀为 setup 改进。

需要客观指出的是：这套面向 Agent 的工程范式目前仍然处于早期探索者（early-adopter）实践阶段。Kiro 认为，最佳代码审查组织方式仍在持续探索，专门面向 Agent 设计的工具链与测试体系也尚未完全成熟；如何合理委派任务、如何拆解复杂长程目标以及何时介入，当前依然高度依赖工程师个人的经验积累。

从简单的对话补全转向构建由 Agent 驱动的工程基础设施，并非一键切换的过程。Kiro 提醒，前几周的速度会更慢，并需要投入数周完善环境——理清模块边界、补齐测试与规则文件、搭建可靠的自动化验证环境。

如果团队希望从现在开始逐步探索，可以根据这 10 条原则整理出如下起步顺序：

1. 夯实代码库基础：补齐核心模块的 README 与架构文档，明确模块解耦与强类型定义，确保本地构建与测试反馈快速可靠；
2. 跑通首个验证闭环：选择边界清晰的独立模块，编写明确预期行为的测试脚本，尝试交付带有自愈验证的 30 分钟级任务；
3. 逐步沉淀规则与工具：在初期保持人工逐行审查以校准模型表现，对反复出现的阻碍进行根因分析，沉淀团队的 Steering 文件、操作 Skill 与必要 CLI/MCP 接口；
4. 拓展全流程协同并管理注意力：将方案起草、排障调查与文档更新逐步纳入协同，同时明确注意力预算，保持对系统质量与个人工作节奏的合理把控。