Agent-native 应用：把“功能”变成“结果”

这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”。核心在于：让代理拥有与用户同等的操作能力（UI 能做的，代理也能通过工具做到），并把工具设计成足够原子化的“积木”。这样，新功能往往不再是写代码，而是写一段描述结果的提示词；同时，用户提出的意外需求会推动系统“涌现”出新用法，并反过来指导你补齐工具与能力缺口。

五个核心原则

• 对等（Parity）：任何 UI 动作，代理都应能通过工具实现同样的结果；否则代理会卡死。
• 粒度（Granularity）：工具是原子能力；“功能”是代理在循环中用工具达成的结果。改行为优先改提示词，而不是重构代码。
• 可组合（Composability）：有了原子工具 + 对等能力，就能通过新提示词快速拼出新“功能”（开发者/用户都能做）。
• 涌现能力（Emergent capability）：用户会提你没设计过的需求；代理若能组合工具完成，就是新机会；若失败，则暴露工具缺口。
• 持续变好（Improvement over time）：通过沉淀上下文（context 文件）与迭代提示词，应用可在不发版的情况下持续变强。

落地方法（把原则变成工程实践）

• 先做“能力地图”：列出用户能做的事，逐项确认代理具备创建/读取/更新/删除（CRUD）能力，避免“能新建不能修改/删除”的断腿体验。
• 先原语、后领域工具：先用文件、bash、读写等基础工具跑通；再为高频模式加领域工具，用于效率、校验、术语锚定，但不要把“判断”写进工具里。
• 文件作为通用接口：文件天然可读、可审计、可迁移，代理也最擅长操作；内容放文件、结构化高频数据放数据库（或混合：文件作可读真相，DB 做索引与性能）。
• 明确完成信号：不要靠“看起来差不多了”判断结束；让工具/编排层返回明确的 complete 信号，避免无限循环或半成品。
• 透明的代理行为：工具调用、进度、状态变化要让 UI 可见；“沉默的代理”会让用户觉得坏了。
• 把“授权”做成产品能力：根据风险与可逆性决定自动执行还是强确认；尤其是发送邮件、发布内容等高风险动作。

对移动端的启示

• 移动应用容易被后台杀死，代理任务却可能很长：需要checkpoint/恢复机制，尽可能在每次工具结果后存档。
• iCloud 之类的文件同步能让多设备共享“同一工作区”，但要处理冲突与未下载文件等边界。

原链接：https://every.to/guides/agent-native

#AgentNative #软件代理 #AI产品 #工具调用 #产品架构

every.to

Agent-native Architectures: How to Build Apps After Code Ends

A new software paradigm for the AI age