近期，完全由 Claude code 自主编程开发软件已经成为现实，人们惊呼编程已经终结，该领域的奇点已至：革了程序员再革打工人：Anthropic 发布 Cowork，Claude Code 走进数字办公自动化。

那AI时代的软件应该如何构建，架构长啥样？

Every 的 CEO 兼创始人 Dan Shipper 与 Claude 联合发布了一个指南：编程终结后的应用构建之道，原生智能体架构，AI 时代新的软件范式。

Every 这家公司本身就非常有意思。

公司是一家专注于科技前沿内容的媒体和软件公司，业务众多，但公司仅有 15 名员工，工程师几乎不用编写代码。是真正的 AI First（AI 至上）运营模式的最典型例子。

这篇指南非常值得开发者深入阅读，它展现了未来 AI 软件形态的雏形。

一个容易理解的比喻

想象一下我们过去常见的厨房。

这个厨房里堆满了各种高科技但功能单一的电器：一台只能烤面包的烤面包机，一台只能做奶昔的奶昔搅拌器，还有一台只会炒鸡蛋的炒蛋机。

如果你想吃一份培根鸡蛋三明治，你得按顺序操作三台不同的机器。如果你想发明一道新菜，比如奶昔煎蛋卷，那你只能等厂家发明并出售一台奶昔煎蛋卷机。

这就是我们今天大多数手机应用（App）的工作方式。它们有很多按钮和功能，但每个都只能做开发者预先设定好的事情。

现在，我们来看看 Agent-Native 这个神奇厨房。

这个厨房里没有那些复杂的单一功能电器。取而代之的，是一位拥有超高智慧的机器人厨师助理（也就是我们的智能体 Agent）。

这位助理没有做吐司按钮，但它有一套非常基础、却极其灵活的工具：一把刀、一个平底锅、一个炉子、一个搅拌机，以及一个装满食材的食品柜。

你不需要按任何按钮，你只需要和这位助理说话。

你可以对助理说：给我来片吐司。 它知道如何用刀切下面包，用平底锅加热，然后递给你。任何你能在厨房里亲手做到的事，这位助理都能做到。这就是对等性。

因为助理的工具都是最基础的（刀、锅），所以你可以提出新点子。我今天想来点特别的，做个培根鸡蛋三明治，但面包要用蒜蓉黄油烤。 助理完全能理解。它会用它的基础工具，以一种新的组合方式，创造出一道它从未被编程去制作的菜肴。你仅仅通过描述，就创造了一个新功能。这就是可组合性。

有一天，你对它说：我有一些牛油果、番茄、洋葱和青柠，给我来点惊喜！ 助理利用它的基础工具和对食物的理解，为你发明了墨西哥牛油果酱。你从没想过要点这道菜，但助理自己涌现出了这个想法。这就是涌现能力。应用能做出开发者都未曾想到的事情。

助理还记得你喜欢吃辣。下次你点菜时，它可能会主动问：要不要加点辣椒？ 它在不断学习和成长，而不需要硬件升级。这就是持续改进。

开发 Agent-Native 应用，就像是设计这个神奇厨房。

开发者不再是去制造一台台功能固定的机器（App 功能），而是创造一个灵活的空间，里面有一位聪明的助理和一套基础而强大的工具。

这让用户几乎可以完成任何他们能描述出来的事情，使得未来的应用比以往任何时候都更强大、更个性化、也更有创造力。

我们不再被按钮所限制，唯一的限制，将是我们的想象力。

指南核心解读

下面是翻译整理的指南核心内容，建议再去研读原文：

https://every.to/guides/agent-native

软件智能体（Software Agent）如今已具备可靠的工作能力。Claude Code证明了大语言模型在拥有访问命令行（bash）和文件系统等工具，并能在循环中持续运行直至达成目标时，能够自主完成复杂的多步骤任务。

而且，一个惊人的发现是：一个出色的编码智能体，本质上也是一个出色的通用智能体。

支撑 Claude Code 重构代码库的同一架构，也能够让智能体整理您的文件、管理您的阅读列表或自动化您的工作流程。

Claude Code 软件开发工具包（SDK）的出现，使得这一切变得触手可及。

您可以构建这样的应用程序：其中的功能不再是您编写的代码，而是您描述的结果。

这些结果由一个配备了工具的智能体，在循环中不断操作直至达成。

这开启了一个全新的领域：以 Claude Code 的工作方式为核心，并将其应用于编码之外的广阔天地。

Agent-Native 架构建立在五个核心原则之上，它们共同定义了这类应用的构建理念与实践方向。

五大核心原则实践细节

对等性是 Agent-Native 架构的基石。

想象一个笔记应用，它拥有创建、组织和标记笔记的精美用户界面。当用户提出请求：创建一个笔记，总结我的会议内容，并将其标记为紧急，如果用户界面可以完成但智能体无法完成，那么这个智能体就是不完整的。

实现对等性的关键在于确保智能体拥有的工具（或工具组合）能够实现与用户界面相同的结果。 这并非要求界面上的每个按钮都与一个工具有一一对应的关系，而是要确保最终能达成同样的操作效果。

实践准则： 在为应用添加任何新的界面功能时，都必须反问：智能体能否实现同样的结果？如果不能，就需要为其补充必要的工具或基本操作单元。

一个能力地图可以帮助我们理清思路：

检验标准： 随机选取一个用户可以在界面中完成的操作，向智能体描述这个操作，看它是否能够成功完成。

核心的思维转变在于：智能体是基于判断力去追求一个结果，而不是执行一个预先编排好的序列。 它能够处理意外情况，调整策略，或者提出澄清性的问题。整个循环会一直持续，直到最终结果达成。

工具的原子化程度越高，智能体使用它们的灵活性就越强。

如果您将决策逻辑捆绑在工具中，那无异于将判断力重新移回了代码层面，限制了智能体的自主性。

可组合性使得开发者和用户都能通过编写提示来创造新功能。

您可以发布新的提示作为新功能，用户也可以通过修改或创建自己的提示来定制化应用行为。

例如，想增加一个每周回顾功能，只需编写一个提示：回顾本周修改过的文件，总结关键变更。根据未完成事项和临近的截止日期，为下周建议三个优先事项。

智能体将自动调用 list_files、read_file 等工具，并运用其判断力来完成这个任务。您描述了一个结果，智能体则通过循环操作直至达成该结果。

实现可组合性的前提是： 工具必须足够原子化，以便能够以您未曾预料到的方式进行组合；同时，智能体必须与用户拥有对等（Parity）的能力。如果工具封装了过多的逻辑，组合性就会被打破。

涌现能力是 Agent-Native 应用最激动人心的特性之一。

您的应用能够处理您在设计之初并未明确预见到的任务。

例如，用户可能会提出：交叉比对我的会议记录和任务列表，告诉我哪些是我已承诺但尚未安排时间的任务。 您并未专门构建一个承诺追踪器，但只要智能体能够读取笔记和任务，它就能完成这个请求。

这揭示了所谓的 潜在需求 (Latent Demand)。您无需猜测用户想要什么功能，而是通过观察他们向智能体提出的请求来发现需求。

当某种模式浮现时，您可以通过开发领域特定的工具或专用的提示来优化它。您不是在预测需求，而是在发现需求。

这彻底改变了产品开发的方式。您不再需要预先构想所有功能，而是致力于创建一个能力强大的基础平台，并从涌现出的用户行为中学习和演进。

Agent-Native 应用可以通过多种方式实现持续改进，而不仅仅依赖于代码更新。

•积累上下文： 智能体在多次会话中保持状态，记录已存在的内容、用户的操作历史以及哪些方法是有效的。

•多层次的提示优化：

•开发者层面： 为所有用户发布更新的、更优化的系统提示。

•用户层面： 用户可以根据自己的工作流修改和定制提示。

•智能体层面（高级）： 智能体可以基于反馈进行自我调整。

•自我修改（高级）： 能够编辑自身提示或代码的智能体需要配备完善的安全机制，例如审批流程、检查点、回滚路径和健康检查。这些机制仍在探索中，但上下文积累和提示优化是已经被验证的有效方法。

从基本单元到领域工具

构建 Agent-Native 应用时，工具的设计和演进是一个关键过程。正确的策略是从最基础、最通用的工具开始，逐步发展到针对特定领域的专用工具。

从纯粹的基本单元开始： 最初，只为智能体提供最纯粹的基本操作单元（Primitives），例如 bash 命令、文件操作（读、写、移动）和基础的存储功能。这有助于验证整体架构的可行性，并揭示智能体在实际工作中真正需要哪些能力。

观察并添加领域工具： 随着用户与智能体互动，某些操作模式会反复出现。此时，可以有目的地添加领域特定的工具（Domain Tools）。这些工具主要用于：

•锚定词汇 (Vocabulary): 例如，一个 create_note 工具能教会智能体在您的应用生态中笔记具体指什么。

•增加护栏 (Guardrails): 某些操作需要进行验证，而这些验证不应完全交给智能体的判断力。例如，删除重要数据的操作可能需要一个带有确认步骤的领域工具。

•提升效率 (Efficiency): 对于常见的、由多个基本单元组成的操作，可以将其捆绑成一个领域工具以提高速度和降低成本。

领域工具的设计原则： 从用户的角度看，一个领域工具应该代表一个独立的概念性动作。它可以包含机械性的验证逻辑，但关于做什么或是否做的判断力应该保留在提示（Prompt）中。

领域工具应是快捷方式，而非关卡。

即使引入了 create_note 这样的领域工具，智能体仍应能使用底层的 write_file 等基本单元来处理边缘情况。

这保留了系统的可组合性和涌现能力。默认应该是开放的，只有在涉及安全或数据完整性等特定原因时，才应有意识地进行限制。

随着应用的发展，某些由智能体编排的操作可能会因为性能或可靠性的要求，需要被优化为固化的代码。

这个“毕业”过程通常遵循以下路径：

1.智能体使用基本单元循环： 灵活性最高，用于验证概念。

2.添加领域工具： 针对常见操作，速度更快，但仍由智能体编排。

3.实现为优化代码： 对于高频路径（Hot Paths），将其实现为确定性的、高效的代码。

即使一个操作毕业到了代码层面，智能体本身也应该能够触发这个优化后的操作，并在遇到优化路径无法处理的边缘情况时，能够回退到使用基本单元。毕业关乎效率，但对等性原则依然适用。

智能体天然擅长处理文件。

Claude Code 的成功很大程度上归功于 bash + 文件系统这个历经考验的智能体交互界面。

在 Agent-Native 架构中，将文件作为核心的通用接口具有多重优势。

构建健壮的 Agent-Native 应用需要一些特定的实现模式，以确保智能体与用户、与系统之间的高效协作。

智能体和用户应该在同一个数据空间中工作，而不是被隔离在各自的沙箱里。

这种模式带来了显著的好处：

•透明度与可控性： 用户可以随时检查、修改甚至覆盖智能体的工作成果。

•协同构建： 智能体可以基于用户创建的内容继续工作，反之亦然。

•无需同步层： 由于共享同一数据源，避免了在智能体和用户界面之间构建复杂的数据同步逻辑。

一个典型的目录结构可能如下：

只有在确实需要（例如为了安全或防止关键数据损坏）时，才应考虑使用沙箱隔离。默认应为共享工作空间。

为了让智能体有效工作，它必须清楚地了解当前的工作环境。系统提示（System Prompt）应该动态地注入关键上下文信息，通常包括：

•可用资源：

•自身能力：

•近期活动：

对于长时间运行的会话，应提供一种刷新上下文的机制，以确保智能体始终掌握最新的信息。

当智能体执行操作时，用户界面应立即反映其变化。

一个沉默的智能体给人的感觉是它坏掉了。

建立信任的关键在于过程的可见性。可以通过一个事件系统将智能体的内部状态实时传递给 UI。

一个典型的智能体事件枚举可能如下：

没有静默操作。 智能体引发的任何变化都应立即可见。

这包括：

•实时显示思考过程。

•显示当前正在执行的工具。

•增量流式生成文本。

•实时更新任务列表的进度。

产品影响与移动端考量

Agent-Native 架构不仅影响应用的构建方式，也深刻地改变了产品的用户体验和演进路径。

渐进式披露 (Progressive Disclosure)：Agent-Native 应用应该做到入门简单，但能力无上限。

简单的请求应该能立即得到满足，而高级用户则可以驱使系统以意想不到的方式工作。

Excel 是这方面的一个典型例子：它可以用来制作一个简单的购物清单，也可以用来构建复杂的金融模型。

Agent-Native 应用也应具备这种品质。界面保持简洁，但其能力随着用户请求的复杂度而扩展。

•简单的入口： 基本请求无需学习曲线即可工作。

•可发现的深度： 用户在探索中不断发现新的强大功能。

•没有天花板： 高级用户可以推动系统超越您最初的设想。

如前所述，Agent-Native 应用的核心产品策略是构建一个能力强大的基础，观察用户要求智能体做什么，然后将浮现的模式正式化。

•传统产品开发： 想象用户想要什么 -> 构建它 -> 验证假设是否正确。

•Agent-Native 产品开发： 构建一个能力强大的基础 -> 观察用户请求 -> 将涌现的模式正式化。

智能体成为了一个研究工具，帮助您理解用户真正的需求。

随着时间的推移，您可以：

•为常见模式添加领域工具，使其更快、更可靠。

•为频繁的请求创建专用提示，使其更易于发现。

•移除未被使用的工具，简化系统。

当智能体开始采取主动行为（即未经用户明确请求而自行启动任务）时，必须仔细考虑授予其多大的自主权。一个核心的考量框架是 风险 (Stakes) 和 可逆性 (Reversibility)。

此框架适用于智能体的主动行为。如果用户明确要求（例如，发送那封邮件），这本身就是一种审批，智能体应直接执行。

移动设备是 Agent-Native 应用的头等平台，它带来了独特的约束和机遇。

移动端的优势：

•文件系统： 智能体可以自然地使用文件操作，与在其他平台上的工作方式一致。

•丰富的上下文： 移动设备是一个围墙花园，但您获得了访问权限。健康数据、位置、照片、日历等上下文是在桌面或 Web 上不存在的。

•本地应用： 每个用户都有自己的应用副本，这为应用的自我修改、分叉和个性化演进创造了可能。

•应用状态同步： 借助 iCloud，所有设备共享文件系统，智能体的工作成果可以无缝同步，无需服务器。

智能体任务可能是长时间运行的，而移动操作系统（如 iOS）会在应用进入后台几秒钟后就可能将其挂起甚至终止。

因此，移动端的 Agent-Native 应用必须具备完善的 检查点 (Checkpointing) 和恢复 (Resuming) 机制。

•检查点： 在应用进入后台、每次工具调用后或长时间操作期间定期保存会话状态（包括智能体类型、消息历史、任务列表、自定义状态等）。

•恢复： 在应用返回前台时，加载被中断的会话，向用户显示恢复提示，并从上次中断的地方继续执行。

一种推荐的移动端存储策略是 iCloud 优先，本地回退。

优先使用 iCloud 容器进行存储以实现跨设备同步，当 iCloud 不可用时，则回退到本地文档目录。

通过一个存储抽象层来管理文件路径，使应用的其他部分无需关心具体存储位置。

iOS 通常只提供大约 30 秒的后台执行时间。

应利用这段时间完成当前的工具调用、保存检查点，并平稳地过渡到后台状态。

对于需要数小时运行的真正长时任务，可以考虑使用服务器端协调器，而移动应用则作为查看器和输入设备。

高级模式

对于需要与外部 API（如 HealthKit、GraphQL 端点）深度集成的场景，为每个端点构建一个静态工具是脆弱的。一种更高级的模式是动态能力发现。

静态映射的问题：当 API 增加新功能时，您需要修改代码并发布新版本。

动态发现的模式：

1.提供一个 list_available_types() 工具，用于在运行时发现所有可用的数据类型（例如，返回 [ steps", "heart_rate", "sleep"]）。

2.提供一个 read_data(type) 工具，可以读取任何发现的类型。

这种模式将粒度化推向了逻辑上的极致。

您的工具变得如此原子化，以至于它们可以处理您在构建时甚至不知道存在的类型，从而极大地增强了应用的灵活性和面向未来的适应性。

CRUD 完整性：对于系统中的每一个实体，都应验证智能体是否拥有完整的创建（Create）、读取（Read）、更新（Update）和删除（Delete）能力。

一个常见的失败案例是：您构建了 create_note 和 read_notes，却忘记了 update_note 和 delete_note。当用户要求智能体修正我会议记录里的那个错字时，智能体便无能为力。

审计方法： 列出系统中的所有实体，并逐一核对智能体是否具备针对该实体的全部四种 CRUD 操作能力。

在构建 Agent-Native 应用时，需要警惕一些常见的、看似合理但实际上偏离了核心理念的方法。

成功标准

一个真正的 Agent-Native 应用应该满足以下标准：

架构层面：

•对等性： 智能体能实现用户通过 UI 所能做的一切。

•粒度化： 工具是原子化的，领域工具是快捷方式而非关卡。

•可组合性： 可以通过编写新提示来添加新功能。

•涌现能力： 智能体能完成您未曾明确设计的任务。

•行为可塑性： 改变行为意味着编辑提示，而不是重构代码。

实现层面：

•系统提示包含可用的资源和能力。

•智能体和用户在同一数据空间中工作。

•智能体的行为能立即在 UI 中得到反映。

•每个实体都具备完整的 CRUD 能力。

•在适用的情况下，外部 API 采用动态能力发现模式。

•智能体明确地信号任务完成。

产品层面：

•简单的请求无需学习即可立即工作。

•高级用户可以以意想不到的方式推动系统。

•您通过观察用户向智能体提出的要求来了解他们想要什么。

•审批要求与操作的风险和可逆性相匹配。

移动端：

•通过检查点/恢复机制处理应用中断。

•采用 iCloud 优先、本地回退的存储策略。

•明智地利用有限的后台执行时间。

指南给出了一个终极测试：描述一个属于您应用领域范畴内，但您并未为其构建特定功能的结果，然后将其交给智能体。如果它能够自主地找出实现该结果的方法，并在循环中不断操作直至成功，那么，恭喜您，您构建了一个真正的 Agent-Native 应用。如果不能，这表明您的架构还过于受限。

参考资料：

https://every.to/chain-of-thought/agent-native-architectures-how-to-build-apps-after-the-end-of-code

https://every.to/guides/agent-native