Dan Shipper（Every 的联合创始人）和 Claude 联手写了一份技术指南，试图给出答案。

　　它系统性地总结了在这个 AI Agent 能够可靠工作的时代，我们应该如何重新思考软件架构：不是把 Agent 当作一个附加功能，而是让它成为软件的一等公民。

　　Dan 和团队已经用这套方法论构建了 Reader、Anecdote 等产品，里面的模式都经过了验证。

　　Claude Code 证明了一件事：一个大语言模型，只要给它 bash 和文件工具，让它在循环中运行直到目标达成，就能自主完成复杂的多步骤任务。

　　这里有一个令人惊讶的发现：一个真正优秀的编程 Agent，其实就是一个真正优秀的通用 Agent。让 Claude Code 能重构代码库的那套架构，同样能让 Agent 整理你的文件、管理你的阅读清单、或者自动化你的工作流程。

　　Claude Code SDK 让这一切变得触手可及。你可以构建这样的应用：功能不是你写的代码，而是你描述的结果。由一个拥有工具的 Agent，在循环中运行，直到结果达成。

　　这开辟了一个新领域：像 Claude Code 那样工作的软件，应用到编程之外的无数场景中。

　　这是基础性原则。没有它，其他一切都免谈。确保 Agent 拥有能够完成 UI 所能做的一切的工具。

　　想象一个笔记应用，用户可以创建、整理、标记笔记。用户说：「创建一个会议总结笔记，标记为紧急。」如果 UI 能做但 Agent 做不到，Agent 就卡住了。

　　解决方案：确保 Agent 拥有能够实现 UI 所能达成的一切结果的工具（或工具组合）。这不是 UI 按钮和工具的一对一映射，而是实现相同的结果。

　　关键转变在于：Agent 是在用判断力追求一个结果，而不是执行一个编排好的序列。它可以遇到意外情况、调整方法、或者提出澄清性问题，循环持续运行直到结果达成。

　　工具越原子化n1clash 内核编译版本，Agent 使用它们的灵活性就越高。如果你把决策逻辑打包进工具，你就把判断力从 Agent 那里移回了代码里。

　　例子：「把我的会议笔记和任务列表交叉对照，告诉我哪些是我承诺了但还没安排的。」你没有构建承诺追踪器，但如果 Agent 能读取笔记和任务，它就能完成这件事。

　　这揭示了潜在需求。你不是猜测用户想要什么功能，而是观察他们让 Agent 做什么。当模式出现时，你可以用专门的工具或提示词来优化它们。但你不需要预料到它们，你是发现它们的。

　　从纯基础能力开始：bash、文件操作、基础存储。这证明架构可行，并揭示 Agent 真正需要什么。

　　领域工具的规则：它们应该代表从用户角度看的一个概念性动作。可以包含机械性验证，但关于做什么或是否做的判断属于提示词。

　　保持基础能力可用。领域工具是捷径，不是门禁。除非有特定原因需要限制访问（安全、数据完整性），Agent 仍应该能够使用底层基础能力处理边缘情况。

　　注意：即使操作升级到代码，Agent 也应该能够自己触发优化操作，并在优化路径无法处理边缘情况时回退到基础能力。升级是关于效率的，对等性仍然成立。

　　Agent 原生设计的一般原则：为 Agent 能推理的东西设计。最好的代理是对人类有意义的东西。如果人类能看着你的文件结构并理解发生了什么，Agent 大概也能。

　　Agent 在每次会话开始时读取这个文件，并在状态变化时更新它：可移植的工作记忆，无需代码变更。

　　实用指南：日志和状态文件很少冲突。对于用户编辑的内容，考虑显式处理或将 Agent 输出分开。iCloud 通过创建冲突副本增加复杂性。

　　Excel 是典型例子：购物清单或财务模型，同一个工具。Claude Code 也有这个特质。界面保持简单；能力随请求扩展。

　　Agent 原生产品开发：构建一个有能力的基础，观察用户让 Agent 做什么，形式化出现的模式。

　　当用户让 Agent 做某事并且成功了，那是信号。当他们问了但失败了，那也是信号：它揭示了你的工具或对等性的缺口。

　　当 Agent 采取主动行动（自己做事而不是响应明确请求）你需要决定给予多少自主权。考虑风险和可逆性：

　　注意：这适用于主动的 Agent 行动。如果用户明确要求 Agent 做某事（「发送那封邮件」），那已经是审批了——Agent 直接做。

　　自我修改应该是可读的：当 Agent 可以修改自己的行为时（更改提示词、更新偏好、调整工作流）目标是：

　　一个 Agent 可能需要 30 秒、5 分钟或一小时来完成任务。但 iOS 会在几秒不活动后将你的应用放到后台，可能会完全杀死它来回收内存。用户可能在任务进行中切换应用、接电话或锁屏。

　　恢复流程：加载中断的会话 → 按有效性过滤（默认一小时） → 显示恢复提示 → 恢复消息并继续

　　对于真正长时间运行的 Agent：考虑一个可以运行数小时的服务器端编排器，移动应用作为查看器和输入机制。

　　构建每个外部 API 端点的工具的替代方案：构建让 Agent 在运行时发现可用内容的工具。

　　这是原子性推到其逻辑结论。你的工具变得如此原子化，以至于它们可以处理你构建时不知道存在的类型。

　　Agent 作为路由器：Agent 搞清楚用户想要什么，然后调用正确的函数。Agent 的智能用于路由，而不是行动。这可以工作，但你只用了 Agent 能力的一小部分。

　　先构建应用，然后添加 Agent：你用传统方式构建功能（作为代码），然后将它们暴露给 Agent。Agent 只能做你的功能已经做的事情。你不会获得涌现能力。

　　请求/响应思维：Agent 获得输入，做一件事，返回输出。这忽略了循环：Agent 获得一个要实现的结果，运行直到完成，沿途处理意外情况。

　　防御性工具设计：你过度约束工具输入，因为你习惯了防御性编程。严格的枚举，每层验证。这是安全的，但它阻止 Agent 做你没预料到的事情。

　　快乐路径在代码中，Agent 只是执行：传统软件在代码中处理边缘情况：你写了当 X 出错时会发生什么的逻辑。Agent 原生让 Agent 用判断力处理边缘情况。如果你的代码处理了所有边缘情况，Agent 只是一个调用者。

　　工作流形状的工具：analyze_and_organize把判断力打包进工具。把它分解成基础能力，让 Agent 组合它们。

　　上下文饥饿：Agent 不知道存在什么。用户说「整理我的笔记」，Agent 不知道有笔记。修复：将可用资源和能力注入系统提示词。

　　无理由的门禁：领域工具是做某事的唯一方式，而你没打算限制访问。修复：默认开放。保持基础能力可用，除非有特定理由设置门禁。

　　人为的能力限制：出于模糊的安全顾虑而不是特定风险限制 Agent 能做什么。Agent 通常应该能够做用户能做的事情。对破坏性操作使用审批流程，而不是完全移除能力。

　　动态更好时的静态映射：当发现 + 访问模式会给出更多灵活性并使系统面向未来时，为 50 个 API 端点构建 50 个工具。

　　启发式完成检测：通过启发式方法检测 Agent 完成（连续迭代没有工具调用、检查预期输出文件）是脆弱的。修复：要求 Agent 通过完成工具明确发出完成信号。