Agent-native Architecture
来源：Every.to，2026-03
Agent-native 架构是 AI 时代的全新软件范式。Claude Code SDK 让构建这类应用变得触手可及。
一个令人惊喜的发现是：一个真正优秀的编程智能体，实际上也是一个真正优秀的通用智能体。让 Claude Code 能够重构代码库的架构，同样可以让智能体帮你整理文件、管理阅读清单，或自动化你的工作流程。
五大核心原则
1. 对等性（Parity）
无论用户能通过界面做什么，智能体都应该能够通过工具实现。这是基础原则——没有它，其他一切都无从谈起。
测试方法：任选一个界面操作。智能体能完成它吗？
能力映射表有助于验证：界面按钮不需要与工具一一对应，但要能达成相同结果。
2. 粒度（Granularity）
工具应该是原子原语（Atomic primitives）。功能是通过智能体在循环中操作而达成的结果，而非写死的代码。
关键转变：智能体是在用判断力追求结果，而不是执行编排好的序列。它能遇到意外情况、调整方法，或提出澄清问题。
测试方法：要改变行为时，你是编辑提示词还是重构代码？
3. 可组合性（Composability）
有了原子工具和工具对等性，你只需要编写新的提示词就能创建新功能。
想要一个"每周回顾"功能？那只是一个提示词：
回顾本周修改的文件。总结关键变更。
基于未完成的事项和即将到来的截止日期，
建议下周的三个优先事项。
约束条件：这只有在工具足够原子化、能够以你未曾预料的方式组合时才有效。如果工具编码了太多逻辑，组合性就会崩溃。
4. 涌现能力（Emergent capability）
智能体能够完成你没有明确设计的功能。用户提出你未曾预料到的需求，智能体组合工具来完成它们（或失败，揭示一个缺口）。你观察被请求的模式，然后添加领域工具或提示词优化。
测试方法：它能处理你领域中的开放式请求吗？
5. 持续改进（Improvement over time）
Agent-native 应用通过累积的上下文和提示词优化而不断变得更好。与传统软件不同，无需发布代码就能改进：
- 累积的上下文：状态通过上下文文件在会话间持久保存
- 开发者级别的优化：为所有用户发布更新的提示词
- 用户级别的定制：用户为他们的工作流程修改提示词
从原语到领域工具
从纯粹的原语开始（bash、文件操作、基本存储），证明架构有效并揭示智能体真正需要什么。随着模式出现，有意识地添加领域特定的工具：
- 词汇：
create_note工具教会智能体"笔记"在你的系统中是什么意思 - 护栏：某些操作需要验证，不应该留给智能体的判断力
- 效率：常见操作可以捆绑以提高速度和降低成本
领域工具是捷径，不是关卡。除非有特定原因需要限制访问（安全、数据完整性），智能体仍然应该能够使用底层原语来处理边缘情况。默认是开放的；让限制成为一个有意识的选择。
毕业到代码
某些操作需要从智能体编排转移到优化代码，以提高性能或可靠性：
- 智能体在循环中使用原语 — 灵活，证明概念
- 为常见操作添加领域工具 — 更快，仍然是智能体编排
- 对于热点路径，在优化代码中实现 — 快速、确定性
即使当操作"毕业"到代码时，智能体也应该能够直接触发优化操作，并在边缘情况下回退到原语。
文件作为通用接口
智能体天生擅长处理文件。Claude Code 之所以有效，是因为 bash + 文件系统是经过最充分测试的智能体接口。文件接口的优势：
- 已经熟知：智能体已经知道
cat、grep、mv、mkdir - 可检查：用户可以看到智能体创建的内容，编辑它、移动它
- 可移植：导出和备份都很简单，用户拥有他们的数据
- 自文档化：
/projects/acme/notes/是自文档化的，而SELECT * FROM notes WHERE project_id = 123不是
Agent-native 设计的一般原则：为智能体能够推理的事物而设计。如果人类能够查看你的文件结构并理解发生了什么，智能体很可能也能。
反模式
智能体作为路由器
智能体弄清楚用户想要什么，然后调用正确的函数。智能体的智能用于路由，而不是行动。你只使用了智能体能力的一小部分。
先构建应用，再添加智能体
用传统方式构建功能（作为代码），然后将它们暴露给智能体。智能体只能做你的功能已经能做的事情，不会得到涌现能力。
防御性工具设计
过度约束工具输入——严格的枚举、每层验证。这很安全，但它阻止了智能体做你未曾预料到的事情。
工作流程形状的工具
analyze_and_organize 将判断力捆绑到工具中。应该将其拆分为原语，让智能体组合它们。
产品影响
渐进式展示（Progressive disclosure）
入门简单但功能无限强大。基本请求立即生效，高级用户可以朝意想不到的方向推进。Excel 是典型例子：购物清单或财务模型，同一个工具。
潜在需求发现（Latent demand discovery）
构建一个有能力的基础，观察用户让智能体做什么，将出现的模式形式化。你不是试图预先想象每个功能，而是创建一个有能力的基础并从涌现的事物中学习。智能体成为了解用户实际需求的调研工具。
与 SaaS 的区别
| 传统 SaaS | Agent-native |
|---|---|
| 功能是写死的代码 | 功能是提示词描述的结果 |
| 用户操作界面 | 智能体操作工具 |
| 新增功能需要开发 | 新增功能只需要新提示词 |
| 预先想象每个功能 | 从涌现的行为中发现需求 |
关联
- product-trends/agent-native-architecture-three-principles — 三大原则详解（Parity, Granularity, Composability）
- product-trends/overview — Product Trends 总览
- claude-code/overview — Claude Code 是 Agent-native 的典型实现
- harness-engineering/overview — Harness 是 Agent-native 的基础设施
- product-trends/saas-vs-agent-native — SaaS vs Agent-Native：Linear 的视角
智能体执行模式
完成信号
智能体需要一种明确的方式来表示"我完成了"。不要通过启发式方法检测完成。工具应该支持显式的完成信号：
- success — 继续循环
- error — 继续（重试）
- complete — 停止循环
完成与成功/失败是分开的：工具可以成功并停止循环，或失败并发出继续信号以进行恢复。
模型层级选择
并非所有智能体操作都需要相同的智能水平。根据任务复杂度显式选择层级，不要总是默认为"最强大的"：
| 任务类型 | 层级 | 原因 |
|---|---|---|
| 研究智能体 | 平衡 | 工具循环，良好的推理 |
| 聊天 | 平衡 | 对话速度足够快 |
| 复杂综合 | 强大 | 多源分析 |
| 快速分类 | 快速 | 高容量，简单任务 |
CRUD 完整性
对于系统中的每个实体，验证智能体是否具有完整的创建、读取、更新、删除能力。常见失败：你构建了 create_note 和 read_notes，但忘记了 update_note 和 delete_note。用户让智能体"修复我会议笔记中的那个拼写错误"，智能体无法帮助。
移动端考量
移动端是 Agent-native 应用的一流平台。它有独特的约束和机会：
- 文件系统：智能体可以自然地处理文件，使用与其他地方相同的原语
- 丰富的上下文：健康数据、位置、照片、日历——桌面或 Web 上不存在的上下文
- 应用状态同步：使用 iCloud，所有设备共享相同的文件系统，智能体的工作出现在任何地方
挑战：智能体可能需要 30 秒、5 分钟或 1 小时来完成任务，但 iOS 会在几秒钟不活动后将应用置于后台。解决方案包括检查点（Checkpointing）保存状态、恢复机制从中断处继续，以及明智地使用 iOS 提供的有限后台执行时间。
成功标准
终极测试：向智能体描述一个在你的应用域内但你没有为其构建特定功能的结果。它能想出如何完成它，在一个循环中持续操作直到成功吗？
如果是——你已经构建了某种 Agent-native 的东西。
如果不是——你的架构太受限了。