Agent Native Development

转载

这是一篇factory.ai的官网文章，讲了一个agent native的新故事。

不过私以为，factory.ai最大的亮点还是在团队协作，预计在2b市场会有很大的概念接受度。实际效果如何还待验证。不过QoQ增长非常快。

如何使用Agent构建软件

当使用正确时，AI agents为软件开发提供了巨大的杠杆作用。许多开发者认识到这一现实，并希望调整他们的工作流程。然而，一个悬而未决的问题是：你究竟如何以正确的方式使用agents进行构建？

标准的软件开发实践是以非常以人为中心的方式构建的。在前AI时代，最大的瓶颈是编写代码行。有了AI，这种情况正在迅速改变。但如果没有最佳实践，一个类似的新的大型瓶颈将在软件开发生命周期的后期阶段出现：审查和验证。

Agent-Native Development是一种使用自主agents构建软件的规范方法。它允许您显著增加编码输出，同时通过彻底的规划和清晰的验证程序来解决常见的失败模式。

当agent运行完整的内循环时，开发就是agent原生的：收集上下文、规划、实施、运行验证和提交可审查的变更。在此过程中，它会留下推理和决策的清晰轨迹。人类仍然做出架构决策，设置防护栏，并在agent犯错误时进行干预。

核心基础

使用agents构建软件有三个主要原则：

让请求足够精确，以便能够证明成功。
让任务足够小，以便在复合之前解决任何错误的假设。
创建一个适合自动、客观验证而非手动审查的环境。

Agent-native开发的最佳实践与与任何有能力的团队成员合作并无根本不同。区别在于agents需要我们本应一直应用的纪律。

规范就是一切

与agents合作的一个指导原则是，你投入什么就得到什么。您对手头任务的指导或"规范"越精确，agent就越有可能按照您的喜好完成任务。问问自己，"我需要提供什么指导给一个有能力的新员工，这样他们就不需要多次打扰我？"以此作为精确性的直觉检查。

通常，当请求规范不足时是清楚的："修复阻止用户登录的bug"或"改进我们的查询API性能"或"为应用添加Google SSO。"没有锚点。没有边界。没有可衡量的成功。agent会勤奋地探索和猜测，但不可避免地会违反您有但没有明确说明的假设。

让我们比较一个宽松的规范和一个精确的规范：

注意精确版本没有做什么。它不规定内部算法，不命名每个文件，也不淹没在内部行话中。它标记了一个起始位置、失败信号、边界和"完成"的定义。这足以保持循环狭窄，同时为agent留下设计自由。

如果您在编写精确规范时遇到困难，可以利用您的agent来帮助编写更精确的规范。一个简单的请求"帮助我将这个粗略的想法变成一个合适的规范"可以增加成功所需的精确性和结构。

快速自检：您能指向（1）agent应该开始阅读的位置和（2）证明完成的工件吗？如果任何一个答案是模糊的，您仍在头脑风暴。您不能委托您无法定义的内容。

有效的实用工作流程

以下是一些实用的工作流程，您可以采用它们来在今天看到agents的成功。

探索 → 规划 → 编码 → 验证

从一个模仿深思熟虑的人类工作流程的循环开始：

探索：要求agent探索您知道相关的代码库的特定部分。
规划：要求agent提出一个实现您心中任务的计划。审查agent提出的步骤。在进行任何编辑之前缩小范围或边界。
编码：批准小的、范围明确的更改。鼓励检查点提交，以便在必要时可以进行二分查找。
验证：要求客观证明：测试、lint、类型检查，以及限制在约定路径内的diff。提交消息应该解释意图，而不仅仅是"修复东西"。

对于纯逻辑bug，转向测试优先开发。agent编写一个失败的测试，确认它失败，然后实现修复，直到套件变绿且没有覆盖率损失。

对于UI工作，使用视觉迭代循环。提供截图或运行预览，让agent实施，捕获快照，然后迭代直到视觉差异可忽略不计。

选择与任务匹配的循环，而不是到处强制一种模式。

设置成功环境

在仓库根目录保留一个简短的AGENTS.md文件，回答三个问题：

我如何构建、测试和lint？
代码库在高层上是如何组织的？
什么证据必须伴随pull request？

示例：

markdown 复制代码

# MyProject

这是My Project的概述。它是一个用于突出AGENTS.md文件实用性的示例应用。

## 1 核心命令

• 类型检查和lint：`pnpm check`
• 自动修复样式：`pnpm check:fix`
• 运行完整测试套件：`pnpm test --run --no-color`
• 运行单个测试文件：`pnpm test --run <path>.test.ts`
• 启动开发服务器（前端 + 后端）：`pnpm dev`
• 生产构建：`pnpm build` 然后 `pnpm preview`

所有其他脚本都包装这六个任务。

## 2 项目布局

├─ client/ → React + Vite 前端
├─ server/ → Express 后端

• 前端代码仅位于`client/`中
• 后端代码仅位于`server/`中
• 共享的、环境无关的助手属于`src/`

## 3 开发模式和约束

### 编码风格
• TypeScript严格模式，单引号，尾随逗号，无分号。
• 100字符行限制，制表符缩进（YAML/JSON/MD使用2空格）。
• 对公共API使用接口；避免`@ts-ignore`。
• 修复逻辑bug时首先测试。
• UI调整使用视觉差异循环。
• 未经PR描述中的解释，绝不引入新的运行时依赖。

## 4 Git工作流程要点

1. 从`main`分支分支出一个描述性名称：`feature/<slug>`或`bugfix/<slug>`。
2. 在提交之前**在本地**运行`pnpm check`。
3. 仅在您的功能分支上**允许**强制推送，使用
   `git push --force-with-lease`。绝不强制推送`main`。
4. 保持提交原子化；优先选择检查点（`feat: ...`，`test: ...`）。

## 5 每个PR所需的证据

当pull request包含以下内容时是可审查的：

- 所有测试通过（`pnpm test`）
- Lint和类型检查通过（`pnpm check`）
- Diff限制在约定路径内（见第2节）
- **证明工件**
  • Bug修复 → 首先添加失败测试，现在通过
  • 功能 → 展示行为的新测试或视觉快照
- 一段式的提交/PR描述，涵盖意图和根本原因
- 无覆盖率下降，无未解释的运行时依赖

每当您看到您的agents持续失手时，更新此文件。

边界和权限

考虑根据您愿意自动运行的命令类型设置您的风险配置文件。

低风险

文件编辑、格式化、本地测试运行

中等风险

提交、依赖版本升级、schema干运行

高风险

破坏性脚本、生产数据、敏感目录

自动化低/中级层，并坚持对高风险操作进行人工确认。

确定性和可验证环境

当每次运行都是可验证和可重复时，agents会茁壮成长。您应该拥有：

高度规范的格式和lint检查以捕获样式漂移
单元测试和/或组件测试以确认和保留本地行为
在适用时，新添加的失败测试证明您重现了bug或需求
静态扫描和/或安全扫描以确保您没有运输已知漏洞
CI中专注于审查的agent，标记更复杂的设计模式和可维护性问题

现实世界示例

Bug修复：从Issue到PR

编写一个精确的规范，命名起始文件、重现命令和成功证明。agent添加一个失败的测试，观察它失败，只修补允许的路径，重新运行狭窄的测试集，然后运行完整套件。一段式的提交消息解释根本原因和修复。

2-6小时的功能开发

在提示中起草一个迷你PRD：用户故事、受影响的组件、约束和完成定义。首先要求一个计划。将执行分解为检查点------后端API、前端存根、完善。在每个检查点之后，运行针对性测试和一次手动验证检查，然后再绿灯进入下一阶段。

维护和保养

委托那些已经有清晰轨道的苦差事：在一个包内的格式化爆发、意识到changelog的库版本升级，或合并后的文档更新。仍然在每个PR上设置相同的目标检查；自动化不应该绕过质量标准。

当事情出错时

像任何开发工作一样，当范围蔓延或假设被证明错误时，agent任务有时需要路线修正。与人类合作者相同的迭代模式在这里适用。

有agent漂移的警告迹象，如果您看到它们，您应该中断和干预。

在执行过程中重写自己的计划
在声明路径之外进行编辑
声称修复但没有失败的测试来证明它们有效
充满不相关更改的差异膨胀

在事情过于脱轨之前修复将为您节省长期时间。

恢复手册

缩小规范

缩小agent可能接触的目录或测试。

挽救好的部分

保留有效的工件，如失败的测试；还原嘈杂的编辑。

重新开始清理

用改进的指令启动新会话。

接管

当您能告诉agent未能成功时，结对编程最终更改。

决定在拯救分支将花费更多注意力而不是重新运行任务干净时重新开始。

您今天就可以开始

随着agents变得更加复杂，这些明确的许多实践将成为隐式的。但今天采用这种纪律的团队看到的不仅仅是agent协作的好处：更清晰的人类沟通、更好的文档、更一致的结果。

从您的积压工作中选择一个适度的bug或小功能。写三个清晰的句子，说明从哪里开始，如何重现问题，以及什么证明信号表示完成。让agent通过探索 → 规划 → 编码 → 验证运行，审查证据，然后合并。重复几次。您将在样板文件上花费更少的精力，在设计上花费更多，而agent处理苦差事。您越早开始循环，就越早复合其收益。Agent Native Development将向您展示agents在软件开发生命周期中的限制和力量。