像构建 Claude Code 一样构建应用:揭秘 Agent-native 架构的 5 大核心原则

本文永久链接 – https://tonybai.com/2026/01/13/agent-native-architecture
大家好,我是Tony Bai。
软件智能体(Software Agents)现在已经能够可靠地工作了。Claude Code 证明了,只要赋予一个大语言模型(LLM)访问 Bash 和文件系统的权限,并让它在一个循环中运行直到达成目标,它就能自主完成复杂的多步骤任务。
而这里有一个令人惊讶的发现:一个优秀的编程 Agent,本质上就是一个优秀的通用 Agent。
支撑 Claude Code 重构代码库的同一套架构,同样可以用来整理你的文件、管理阅读列表,或自动化你的工作流。通过 Claude Code SDK、Google adk-go等,这种能力变得触手可及。你可以构建一种全新的应用:其功能不再是你写死的代码,而是你描述的结果(Outcome)——由一个装备了工具的 Agent,在一个循环中自主实现。
这开启了一个全新的领域:软件开始像 Claude Code 一样工作,但应用场景远超编程。这就是 Anthropic 与 Dan Shipper 联合发布的最新架构理念 —— Agent-native Architecture(智能体原生架构)。
本文将深入拆解这份文档中的核心原则与架构模式,带你领略这一前沿范式。

核心原则
要构建 Agent-native 应用,我们需要遵循以下 5 大核心原则:
平权 (Parity)
原则: 用户通过 UI 能做的任何事,Agent 必须能通过工具(Tools)完成。
这是基石。如果没有平权,其他一切都无从谈起。你必须确保 Agent 拥有一套完整的工具集,能够覆盖 UI 的所有能力。
随机挑选一个 UI 动作。Agent 能完成吗?这是验证这一原则的测试标准!
颗粒度 (Granularity)
原则: 工具应该是原子级(Atomic)的原语。功能特性(Features)是由 Agent 在循环中通过组合工具达成的结果。
工具是基本能力。功能特性是 Prompt 描述的一个结果,由 Agent 动态组合工具来实现。
要改变软件的行为,你是通过修改 Prompt,还是重构代码?如果是前者,说明颗粒度对了。
可组合性 (Composability)
原则: 拥有了原子工具和平权,你可以仅通过编写新 Prompt 来创造新功能。
比如:想要一个“每周回顾”功能?这只是一个 Prompt:
“检查本周修改过的文件。总结关键变更。基于未完成项和截止日期,建议下周的三个优先级事项。”
Agent 会自动调用 list_files、read_file 并结合自身判断力。你描述结果,Agent 负责循环执行。

涌现能力 (Emergent Capability)
原则: Agent 可以完成你从未显式设计过的任务。
这是 Agent-native 的飞轮效应:
- 你构建原子工具和平权能力。
- 用户提出了你未预料到的需求。
- Agent 组合工具完成了任务(或失败,揭示了工具缺口)。
- 你观察模式,添加领域工具或专用 Prompt 来优化。
- 重复上述过程。
然后,通过观察你的应用能处理领域内的开放式请求,来验证Agent是否具备这种涌现能力。
随时间进化 (Improvement over time)
原则: Agent-native 应用通过积累上下文和 Prompt 优化而变得更好,而无需重新发版。
与传统软件不同,Agent-native的应用可以通过以下方式自我进化:
- 积累上下文: 状态通过上下文文件(Context Files)跨会话持久化。
- 开发者级优化: 你推送更新的 Prompt,所有用户受益。
- 用户级定制: 用户修改 Prompt 以适应自己的工作流。
实践中的原则
有了原则,我们要如何落地?以下是具体的工程实践指南。
解决“平权”问题
想象一个笔记 App。用户说:“总结我关于这次会议的笔记,并标记为紧急。”
如果 UI 能做,但 Agent 做不到,Agent 就会卡住。
修正方案: 建立一张能力映射表(Capability Map)。

每当添加一个 UI 功能时,都要问:Agent 能达成这个结果吗?如果不能,添加相应的原语工具。将这作为一条工程纪律遵守和贯彻!
解决“颗粒度”问题:原子化 vs 捆绑逻辑
要知道:Agent 追求的是通过判断力(Judgment)达成结果,而不是执行死板的序列。
- ❌ 错误做法(捆绑逻辑):
- 工具:classify_and_organize_files(files)
- 问题:决策逻辑是你写死的代码(充斥着if、else等)。要改变行为,必须重构代码。灵活性差。
- ✅ 正确做法(原子化):
- 工具:read_file, write_file, move_file, bash
- Prompt:“整理下载文件夹…”
- 优势:Agent 负责决策并组合工具完成。要改变行为,只需修改 Prompt。Agent 拥有了更强地灵活性。
演进路线:从原语到领域工具
一开始,只提供纯粹的原语(Bash, 文件操作)。这能证明架构可行,并揭示 Agent 真正需要什么。
当模式涌现后,有意识地添加领域工具(Domain Tools):
- 词汇表 (Vocabulary): create_note 工具教会了 Agent 你的系统中“笔记”是什么。
- 护栏 (Guardrails): 某些操作需要验证,不应完全交给 Agent 判断。
- 效率 (Efficiency): 将常用操作打包,提升速度和降低成本。
领域工具的规则: 它们应该代表用户视角的一个概念性动作。它们可以包含机械验证,但不要包含“做什么”或“是否做”的判断——这属于 Prompt。同时,默认保持原语可用,不要为了这种封装而关闭底层权限,除非有安全理由。
升级成为代码 (Graduating to Code)
有些操作因为性能或可靠性原因,需要从“Agent 编排”升级成为“优化代码”。
- 阶段 1: Agent 在循环中使用原语(灵活,验证概念)。
- 阶段 2: 添加领域工具(更快,但仍由 Agent 编排)。
- 阶段 3: 针对热点路径,用优化代码实现(极快,确定性)。
注意: 即使升级为代码,操作时,Agent 仍应保留直接触发该代码的能力,并保留回退到原语的能力以处理边缘情况。
架构模式:文件即通用接口
为什么 Claude Code 如此依赖文件系统?因为 Bash + Filesystem 是最经受考验的 Agent 接口。
- 已知的: Agent 天生懂 cat, grep, mv。
- 可检查的: 用户能直接看到、编辑、移动文件。没有黑盒。
- 可移植的: 导出和备份极其简单。
- 自文档化: /projects/acme/notes/ 这种路径本身就携带了语义,比 SELECT * FROM notes WHERE id=123 更容易让 Agent 理解。
实体作用域目录 (Entity-scoped directories)
这是一种推荐的文件结构模式:
{entity_type}/{entity_id}/
├── primary content (主内容)
├── metadata (元数据)
└── related materials (相关素材)
例如:Research/books/{bookId}/ 包含全文、笔记、来源和 Agent 日志。
context.md 模式
Agent 需要知道它在处理什么。系统 Prompt 应该注入以下内容:
- 可用资源:
“`markdown
## Available Data- 12 notes in /notes
- 3 active projects in /projects
- Preferences at /preferences.md
“`
- 能力 (Capabilities): 描述它能做什么(创建、搜索、整理)。
- 最近活动 (Recent Activity): 用户刚刚做了什么,Agent 上一步做了什么。
文件 vs 数据库
- 用文件: 用户需要读写的内容、配置、Agent 生成的内容、大文本。
- 用数据库: 高频结构化数据、复杂查询、临时状态(Session/Cache)、强关系数据。
冲突处理: 建议采用 Shared Workspace 模式。Agent 和用户在同一个数据空间工作,不搞沙盒。这需要处理并发写入(如 Last-write-wins 或文件锁)。
成功标准与反模式
在构建 Agent-native 应用时,我们经常会不自觉地滑回传统的软件工程思维。以下是具体的反模式对照表:
Agent 作为路由器 (Agent as Router)
- 反模式: Agent 的唯一工作就是分析用户意图,然后调用一个写死的 run_workflow() 函数。
- 问题: 你把 Agent 的智能降级成了 if/else。如果用户需求稍微偏离你的预设(例如:“这次运行工作流但跳过最后一步”),系统就会崩溃。
- 正确姿势: Agent 应该负责执行,而不仅仅是路由。它应该拥有组成该工作流的原子工具,并根据情况决定调用顺序。
“请求/响应”思维 (Request/Response Thinking)
- 反模式: 认为 Agent 就像一个 API:给一个输入,它吐出一个输出。
- 问题: 这完全丢失了 Master Loop(Agent主循环) 的价值。真正的 Agent 是追求结果(Outcome)的。它可能会尝试、失败、分析错误、再尝试,直到结果达成。
- 正确姿势: 给 Agent 一个目标,让它在一个循环中运行,并在过程中处理意外情况。
防御性工具设计 (Defensive Tool Design)
- 反模式: 你因为习惯了防御性编程,所以把工具的输入限制得很死(例如:严格的 Enums,层层校验)。
- 问题: 这虽然安全,但也扼杀了涌现能力。Agent 无法用你没想到的方式使用工具。
- 正确姿势: 默认保持工具开放。除非有明确的安全风险(如删库),否则允许 Agent 传入任何它认为合理的参数。
工作流形状的工具 (Workflow-shaped Tools)
- 反模式: 创建一个名为 analyze_and_organize_files() 的工具。
- 问题: 你把“判断逻辑”捆绑进了工具里。如果要改变组织方式,必须重写代码。
- 正确姿势: 拆解为 read、analyze、move。让 Agent 在运行时决定如何组织。
“幸福路径”思维 (Happy Path in Code)
- 反模式: 在代码里写死了所有边缘情况的处理逻辑(if error_code == 500: retry)。
- 问题: 如果代码处理了所有边缘情况,Agent 就只是一个无脑调用者。
- 正确姿势: Agent-native 架构允许 Agent 用判断力处理边缘情况。如果遇到 500 错误,Agent 可以决定是重试、还是检查网络、还是通知用户。
成功的终极测试 (The Ultimate Test)
描述一个你的应用领域内的结果,但针对一个你从未专门开发过的功能。
看看Agent 能否通过在一个循环中运行,自主搞定它?如果能,你构建的就是一个真正的 Agent-native 应用。
小结:把判断力还给 Agent
当我们谈论 Agent-native 时,我们到底在谈论什么?
其实,这是一场关于“控制权移交”的变革。在传统的软件工程中,程序员试图用代码穷尽所有的逻辑分支,我们追求的是确定性。但在 Agent-native 的世界里,我们学会了放手。
我们不再编写死板的“步骤”,而是提供灵活的“原语”。我们把“如何做(How)”的判断力,从代码中剥离出来,归还给了 Agent。
- 平权 让 Agent 拥有了和人一样的行动力。
- 颗粒度 赋予了 Agent 自由组合的能力。
- 涌现 让我们看到了软件在设计之外的可能性。
这并不意味着代码不重要了,而是代码的角色变了——从“指挥官”变成了“军火库”。你负责提供精良的武器(工具),而 Agent 负责在前线根据战况(上下文)灵活作战。
这,才是 AI 时代软件架构的终极形态。
资料链接:https://every.to/guides/agent-native
你的 Agent 构想
Agent-native 架构为我们打开了一扇通往无限可能的大门。如果让你用这种架构重新设计你最熟悉的一个应用(比如待办清单、邮件客户端),你会赋予它哪些以前做不到的“涌现能力”?
欢迎在评论区分享你的脑洞! 让我们一起畅想软件的未来形态。
如果这篇文章颠覆了你对软件架构的认知,别忘了点个【赞】和【在看】,并转发给你的产品经理和架构师朋友!
体验最成功的Agent-native应用
Agent-native 不仅仅是一种架构,更是一种全新的开发体验。而目前市面上最成熟、最顶级的 Agent-native 实践,就是 Claude Code 本身。
想要真正理解什么是“原子化工具”?什么是“循环中的判断力”?最好的方式不是空谈理论,而是亲自去体验一个优秀的 Agent 是如何工作的。
欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。我们将深入 Claude Code 的实战场景,带你亲眼见证它如何利用这些架构原则,把一个模糊的需求变成完美运行的代码。
扫描下方二维码,开启你的AI原生开发之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
- 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
- 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
- 想打造生产级的Go服务,却在工程化实践中屡屡受挫?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.
Related posts:
评论