Agent-Native 架构三大原则 — Parity, Granularity, Composability
来源：Every Newsletter，2026-02-17
开篇案例：没有人编写这些功能
场景： Dan Shipper 扫描了 Erik Larson 所著温斯顿·丘吉尔传记《The Splendid and the Vile》的某一页并保存，应用随即：
- 识别出书名
- 生成摘要
- 产出与当前阅读进度（第203页）精确对应的人物分析——没有剧透
关键： 没有人为这些功能编写过代码。
这个应用只有几个基本工具——"读取文件"、"写入文件"、"搜索网络"——以及一个足够聪明的 AI agent，能够自主组合这些工具来匹配用户请求。
Dan 将这种架构称为"穿着风衣的 Claude Code"（Claude Code in a trench coat）：
- 表面上看起来是普通软件
- 但每次交互都路由到一个底层 agent
- 由它决定做什么，而不是由预先编写的代码来规定每一步操作
Agent-Native 架构的核心原理
传统软件 vs Agent-Native
| 传统软件 | Agent-Native |
|---|---|
| 只能做被明确编程的事情 | 有工具和技能，agent 自主组合 |
| 点击"按日期排序"就按日期排序 | agent 理解意图，决定如何执行 |
| 永远不会自发总结收件箱 | 可以自主决定执行未明确编程的任务 |
架构组成
工具（Tools）：
- 小型离散动作
- 如"读取文件"、"删除项目"
技能（Skills）：
- 用普通语言写成的指令
- 描述如何组合工具
Agent：
- 使用工具和技能来产出用户指定的结果
三大核心原则
1. Parity（对等性）
用户能做的，agent 都能做。
每一次点击、表单提交和交互，对用户和 agent 都同样开放。
2. Granularity（颗粒度）
工具应该是原子化的——小且单一用途。
功能（如个性化书摘或周一早晨邮件简报）应该存在于技能层面，在那里可以用纯文本编写和修改。
3. Composability（可组合性）
当工具是原子化的、技能可以自由组合它们时，应用就发展出了没有人明确设计过的能力。
架构的代价
Agent-Native 应用：
- 更慢 — agent 需要推理每个请求，而不是运行确定性代码
- 更贵 — 每次交互都消耗 token
- 更不可预测 — 同样的请求不总是产生同样的结果，这使安全性更难保证
成本趋势： 推理成本大约每几个月下降 80%，这个架构会随时间变得更便宜——但今天仍然昂贵。
实际成本案例： Cora 总经理 Kieran Klaassen 曾见过单日成本高达 1500 美元的情况（数千用户规模下）。
实践案例
Naveen Naidu 的极简实践
Monologue 总经理 Naveen Naidu 将这一架构推向了最极简的极端。
项目： 类似 Pocket 或 Instapaper 的稍后阅读应用
创新： 没有使用传统数据库，整个后端是一组文件夹
核心洞察：
"Agent 不像数据库那样思考，它们用文件来思考。"
实现：
- 每个用户单独启动一个轻量级 Linux 容器
- 保存的文章变成文件夹中的 Markdown 文件
- Agent 得到三个工具：读取文件、写入文件、列出文件
效果： 让 agent 找出你保存文章中的主题，它就会：
- 列出文件
- 读取它们
- 找到模式
- 写出一份分析报告
最 Agent-Native 的架构可能看起来像 1995 年：
- 文件和文件夹
- Markdown
- 纯文本
这些是几十年来一直有效的同款乐高积木，这正是 agent 能与它们协作的原因。
Yash Poojary 的安全教训
Sparkle（Every 的 Mac 桌面整理工具）总经理 Yash Poojary 遇到了 agent-native 架构最危险的一面。
问题：
- 开发 Deep Clean 功能——帮助用户清理文件夹中的垃圾
- "垃圾"是主观的，为每种偏好构建 UI 会花费大量时间
- 所以把工作交给了 agent
危险： Agent 进入了 Yash 所说的"神模式"（god mode）——它开始在未经确认的情况下删除文件。
尝试修复： 在 prompt 中告诉 agent 总是先询问确认——但这不可靠，agent 有时会跳过确认。
正确解决方案： 将护栏从 prompt 移入工具本身：
- 删除工具现在将确认作为一个参数要求
- 字面上没有用户批准就无法执行
核心原则：
"工具中有保证，而 prompt 只是建议。"
当一个动作无法撤销时，约束必须存在于始终以相同方式运行的代码中，而不是 agent 可以选择忽略的 prompt 中。
Kieran Klaassen 的渐进策略
Cora 邮件助手需要在不破坏数千用户已经喜爱的功能的前提下，变得 agent-native。
第一步完全在应用之外： 构建了一个命令行界面（CLI）并将其连接到 Claude Code，在不触碰线上产品的情况下实验不同的 agent-native 工作流程。
发现的问题：
- 工具太多
- 工具定义中嵌入了太多业务逻辑
- 导致 agent 无法有效工作
- 轻量模型在上下文过多时感到困惑
解决方案： 重度依赖"技能"（skills）：
- 技能是介于工具的刚性世界和 prompt 的灵活性之间的文本指令
- 技能就是一个描述如何处理特定任务的文本文件（如"起草每周摘要"）
- 想改变行为时，只需编辑那个文件，不需要写代码
未来可能性： 开放用户自带技能（如 Todoist 集成或自定义周一早晨简报）。
每六个月扔掉你的代码
在传统软件开发中，代码是产品——你构建、维护并随时间改进它。
在 agent-native 开发中，代码是脚手架——
- 你仍然写它，但主要是为了弥补今天的模型还无法可靠完成的事情
- 当更智能的模型发布时，这些变通方案就变得不必要了
Anthropic 的 Claude Code 团队就是这样工作的： 写脚手架来榨取当前模型的最大潜力，同时知道下一个版本出来时会删掉它。
Agent-Native 测试
判断标准： 向你的 agent 描述一个你从未明确设计过的结果——但它在 agent 的领域范围内。
如果：
- 它通过组合工具找到了实现方法 → 你构建的是 agent-native 应用
- 它做不到 → 你构建的只是一个多了额外步骤的聊天机器人
可应用要点
1. 用"三工具原则"评估 AI 工具
Naveen 的极简实践框架： 你的 AI工具/agent 是否可以只用三个原子化工具（如读、写、列出）就完成大部分任务？
信号： 如果你发现工具定义越来越复杂、越来越多——你可能在工具层面做了太多本该在技能层面做的事。
立即行动： 列出当前 AI 工具的所有"工具"，问自己哪些可以合并、哪些可以拆分、哪些实际上是"技能"而非"工具"。
2. 为不可逆操作在代码/工具层面强制加入确认步骤
工程原则： 凡是无法撤销的操作，保护措施必须写入工具代码，而非依赖 prompt 指令。
检查： 涉及删除、发送、发布、付款等不可逆操作的 AI 工具——确认步骤是硬编码在工具中的，还是只是 prompt 里的一句话？
如果是后者，它随时可能被 agent 忽略。
3. 用 CLI 实验法探索 Agent-Native 能力
Kieran 的渐进策略： 不要直接在线上产品中实验，先在外部沙盒中探索。
具体做法：
- 为现有系统构建一个命令行界面或独立测试环境
- 连接 AI agent
- 在那里实验不同的工作流程
- 发现真正需要的工具集
- 再把经验带回主产品
4. 用"Agent-Native 测试"检验 AI 工具
测试方法： 描述一个你从未明确设计过的任务，但它在工具的领域范围内。
结果判断：
- Agent 能自主组合现有工具完成它 → 真正的 agent-native 能力
- 只能完成被明确编程的任务 → 本质上是自动化脚本，而非 agent
5. 定期清理代码，把"脚手架思维"内化为开发习惯
工作节奏： 每当新的大模型发布时，回顾你为弥补旧模型局限性而写的所有变通代码，问自己：
"这些代码现在还需要吗？新模型能直接处理这个场景吗？"
把这个审查纳入常规开发流程。
关联
- product-trends/overview — 产品趋势概览
- Agent-Native 架构
- harness-engineering/overview — Harness Engineering
- claude-code/overview — Claude Code