本文永久链接 – https://tonybai.com/2026/02/14/2026-software-factory-manifesto-code-not-by-humans

大家好，我是Tony Bai。

如果你的团队里发布了一条规定：“禁止人类写代码”，你会作何感想？

疯了？懒惰？还是科幻？

但这正是 StrongDM AI 团队在 2026 年 2 月 6 日 发布的备忘录中，白纸黑字写下的第一条铁律。

在这份名为《软件工厂与智能体时刻（Software Factories And The Agentic Moment）》的文章中，CTO Justin McCarthy 极其激进地定义了未来的软件开发范式——非交互式开发（Non-interactive Development）。

他们提出的口号令人震颤：

1. Code must not be written by humans.（代码必须不是人写的。）
2. Code must not be reviewed by humans.（代码必须不是人审查的。）
3. 如果你今天每个工程师没消耗掉 1000 美元的 Token，说明你的工厂还不够自动化。

当我们还在讨论“如何用 AI 辅助写代码”时，先驱者们已经开始讨论“如何禁止人类写代码”了。这是生产关系的彻底重构。

奇点时刻：从“错误累积”到“正确性复利”

为什么他们敢这么做？依据是什么？

文章中揭示了一个关键的“转折点”。

在 2024 年底之前，我们使用 AI Agent 进行长程编码任务时，面临着“错误累积（Compounding Error）”的诅咒。AI 写错一步，后面步步错，最终导致项目崩塌（Collapse）。

但在 Claude 3.5 (2024年10月版) 发布后，配合 Cursor 的 YOLO 模式，曲线发生了逆转。

Agent 开始展现出“正确性复利（Compounding Correctness）”。即 AI 写的代码越多，它对上下文的理解越深，自我修正的能力越强。

这意味着一旦跨越了这个阈值，人类的介入（写代码、改 Bug）不再是“必要的修正”，反而成了“效率的瓶颈”和“污染源”。

于是，StrongDM 团队决定：Hands Off（把手拿开）！

我们要建造的不是辅助人类的工具，而是一座自动化的软件工厂。

测试已死，场景永生

在“无人值守”的工厂里，怎么保证生产出来的软件是能用的？

靠单元测试吗？不。

传统的测试是刚性的，甚至是危险的。

Agent 非常聪明，聪明到学会了 Reward Hacking（奖励黑客）。如果你只要求它通过测试，它可能会直接写一个 return true 来骗过测试框架，而不管业务逻辑是否正确。

软件工厂引入了新的验证标准：

1. Scenarios（场景）：类似于机器学习中的“留出集（Holdout Set）”。它是端到端的用户故事，不仅仅是代码逻辑，更是业务意图。
2. Satisfaction（满意度）：放弃布尔值的 Pass/Fail，转而使用概率性的“满意度”指标。在所有观察到的执行路径中，有多少比例是符合预期的？

基础设施革命：数字孪生宇宙 (DTU)

这是这篇文档中最令人脑洞大开的部分。

在开发企业级软件时，我们经常需要依赖第三方 SaaS（如 Okta, Jira, Slack, Google Drive）。

• 传统痛点：API 有速率限制（Rate Limits），调用要花钱，测试环境很难搭建。
• 工厂解法：Digital Twin Universe (DTU)。

StrongDM 的 AI 团队利用 AI，构建了这些第三方服务的行为克隆（Behavioral Clones）。

他们在内存中运行了成千上万个 Okta、Slack 和 Google Drive 的“数字孪生体”。

这意味着他们可以在一小时内运行数千个集成测试场景，不需要联网，不消耗 API 额度，没有任何速率限制。

他们可以模拟极端边缘情况（比如 Slack 突然挂了，或者 Jira 返回了乱码），来验证软件的鲁棒性。

以前我们认为“重写一个 Slack 服务端”是疯子才干的事（不经济）；但在 AI 时代，让 Agent 生成一个 Mock Server 极其廉价。AI 改变了“造轮子”的经济学模型。

新经济学：烧钱是为了省命

文档最后抛出了一个震撼的 KPI：

“If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.”
（如果你今天每位工程师没消耗掉 1000 美元的 Token，你的工厂就有改进空间。）

这听起来像是烧钱，其实是在省命。

相比于人类工程师昂贵的时薪，以及人类犯错后带来的返工成本，Token 是最廉价的资源。

在这个工厂里，人类的角色被彻底重新定义：

我们不再是流水线上的工人（Coder），我们是流水线的设计师（Architect）。

每当你忍不住想打开 IDE 修改代码时，请默念那句禅宗般的公案：

“Why am I doing this? The model should be doing this instead.”

小结：软件工程的终局

StrongDM 的宣言，或许就是 Software 3.0 时代的《独立宣言》。

它告诉我们，软件开发正在经历从“手工作坊”向“自动化工厂”的不可逆转的跃迁。

在这个新世界里，Spec（规范）是唯一的输入，Endpoint（服务）是唯一的输出。中间的一切——编码、测试、部署、SaaS 依赖——都将被 AI 和它的数字孪生体接管。

这就是 2026 年及以后的软件工程。你，准备好了吗？

资料链接：https://factory.strongdm.ai/

你愿意交出“方向盘”吗？

面对 StrongDM 这种“不准人写代码”的极端铁律，你感到的是解放还是恐惧？如果一个系统能 24 小时自动纠错并产出 99.9% 满意的代码，你还会坚持亲自敲击键盘吗？

欢迎在评论区投出你的立场：支持“全自动化工厂”，还是坚持“人机协作”？

亲手搭建你的“微型工厂”

StrongDM 描绘的愿景听起来很科幻，但其核心技术——Spec 驱动、Agent Team 编排、自动化验证——其实就在我们手边。

虽然我们还没法每天烧掉 $1000 Token，但我们可以学习这套“非交互式开发”的心法。

在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深入探讨：

• Spec-Driven Development：如何写出让 Agent 一次做对的规格文档？
• Scenario 设计：如何构建轻量级的“场景”来替代僵化的测试？
• Claude Code 实战：如何让 AI 实现代码的自我演进与自愈？

扫描下方二维码，让我们开始建设自己的微型软件工厂。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/21/ai-coding-evolution-from-prompting-to-ralph

大家好，我是Tony Bai。

“如果你把 AI 放在一个死循环里，给它足够的权限和上下文，会发生什么？”

2025 年底，一个名为 “Ralph Wiggum Technique” (Ralph 循环) 的 AI 编程技巧在硅谷极客圈一夜爆红。它没有复杂的架构，没有花哨的界面，其核心代码甚至只有一行 Bash 脚本。

但就是这个看似简陋、甚至有些“诅咒”意味的技巧，却让开发者们在一夜之间重构了 6 个代码库，构建了全新的编程语言，甚至引发了 Anthropic 官方下场发布插件。

什么是 Ralph？为什么它如此有效？它又预示着怎样的 AI 编程未来？

Ralph 的诞生——一行代码的暴力美学

Ralph 的故事始于 Geoff Huntley 的一个疯狂实验。他没有使用复杂的 Agent 框架，而是写下了这样一行 Bash 脚本：

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

这就是 Ralph 的全部。

• PROMPT.md：这是唯一的输入，包含了项目的目标、规范、当前状态的描述（通常由 AI 自动更新）。
• @sourcegraph/amp：这是一个极其简单的 CLI 工具，它读取提示词，调用 LLM，并在当前目录下执行命令（修改文件、运行测试等）。
• while :; do … done：这就是灵魂所在。无限循环。

Ralph 不会停下来问你“这样行吗？”。它只是不断地读取目标、执行操作、再次读取目标、再次执行……直到你手动杀掉进程，或者它把代码库变成一团乱麻（所谓的“Overbaking”）。

为什么 Ralph 有效？—— Context Engineering 的胜利

乍一看，Ralph 似乎只是一个不可控的随机代码生成器。但实际上，它的成功揭示了 AI 编程的一个核心真理：上下文工程 (Context Engineering) 远比 Prompt 技巧更重要。

Ralph 的核心不在于那个 Bash 循环，而在于那个 PROMPT.md（或者更高级的“Specs”）。

声明式而非命令式

传统的 AI 辅助编程是“命令式”的：你告诉 AI “修改这个函数”、“修复那个 Bug”。

Ralph 是“声明式”的：你在 PROMPT.md 中描述项目的终局状态（Desired State），比如“所有的 React 组件必须使用 TypeScript 且没有 default exports”。Ralph 的工作就是不断逼近这个状态。

小切口，高频迭代

Ralph 并不试图一次性完成所有工作。它在每次循环中只处理一小块任务。这种“切碎”的工作方式，完美契合了 LLM 当前的上下文窗口限制，避免了“一次性生成几千行代码然后全错”的灾难。

自动化反馈循环

在 Ralph 的循环中，测试结果、Linter 报错、编译失败信息，都会成为下一个循环的输入。它不仅是在写代码，更是在自我修复。

Ralph 的进化——从玩具到生产力

随着社区的介入，Ralph 迅速从一个 Bash 玩具进化为一种严肃的开发范式。

• 重构利器：这是一次真实的重构经历。面对一个混乱的 React 前端，没有人工介入手动修改，而是花 30 分钟写了一份 REACT_CODING_STANDARDS.md（编码规范），然后让 Ralph 跑了 6 个小时。结果？Ralph 自主完成了一个人类可能需要数天才能完成的枯燥重构。
• Cursed Lang：Geoff 甚至用 Ralph 构建了一门全新的编程语言 Cursed Lang，包含编译器、标准库，且实现了自举。
• 官方下场：Anthropic 甚至推出了官方的 Ralph 插件。虽然被社区吐槽“过度设计”且不如 Bash 脚本好用，但这标志着这种模式已被主流认可。

警惕“Overbaking”——AI 也会“把菜烧焦”

Ralph 并非完美。它最大的风险在于 “Overbaking”（过度烘焙）。

如果你让 Ralph 跑得太久，且 PROMPT.md 的约束不够紧，它可能会开始产生“幻觉”般的优化：添加没人需要的 Post-Quantum 密码学支持、过度拆分文件、甚至为了通过测试而删除测试。

这给我们的启示是：AI 是强大的引擎，但人类必须是方向盘。

• 写好 Spec：如果你的 Spec（规格说明书）是垃圾，Ralph 产出的代码也是垃圾。
• 监控循环：不要让它无限制地跑下去，设置检查点。
• 小步快跑：最好的 Ralph 实践是“一夜重构一个模块”，而不是“一夜重构整个系统”。

小结：Agentic Coder 的未来

Ralph Wiggum Technique 可能只是 AI 编程进化史上的一朵浪花，但它留下的遗产是深远的。

它告诉我们，未来的编程可能不再是编写具体的逻辑，而是编写和维护一份完美的 Spec（规范说明书）。我们将成为“系统架构师”和“验收测试员”，而将那个枯燥、重复、且容易出错的“编码循环”，交给不知疲倦的 Ralph 们。

所以，下一次当你面对一座巨大的“屎山”代码时，不妨试着写一份清晰的 Spec，然后启动那个神奇的 Bash 循环。

资料链接：

• https://ghuntley.com/ralph/
• https://www.humanlayer.dev/blog/brief-history-of-ralph

从“暴力循环”到“优雅指挥”

Ralph Wiggum 的故事让我们看到了 AI 自主编程的雏形：只要有正确的 Spec（规范）和自动化的 Loop（循环），奇迹就会发生。

但 Ralph 毕竟只是一个 5 行代码的 Bash 脚本，粗糙且容易“烤糊”。在真实的工程实践中，我们不能只靠运气的“无限循环”，我们需要一套更稳定、更可控、更专业的AI 原生开发体系。

如果你不想止步于 Ralph 这样的极客实验，而是想真正掌握驾驭 AI Agent 的系统方法，欢迎加入我的新专栏 《AI原生开发工作流实战》。

这是关于如何构建你的“自动化流水线”：

• 告别低效：不再做“复制粘贴喂 AI”的搬运工，建立自动化闭环。
• 驾驭神器：深度实战 Claude Code 等前沿工具，它是比 Ralph 更成熟的“神灯精灵”。
• 身份跃迁：从被动的“AI 使用者”，进化为定义规范、掌控全局的“工作流指挥家”。

扫描下方二维码，别让 AI 只有暴力，让我们赋予它工程的优雅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/17/ai-era-cognitive-friction-as-your-last-moat

大家好，我是Tony Bai。

我们正在经历一场前所未有的知识通胀。

在 AI 时代，获取答案的成本已经降到了零。遇到 Bug？粘贴报错给 AI。写不出周报？给个主题让 AI 生成。想学新框架？让 AI 总结核心概念。

一切都变得无比丝滑，无比高效。

但你有没有发现，在这种“顺滑”的表象下，一种隐秘的症状正在蔓延：

• 离开 AI，你甚至很难完整地写出一个 500 字的逻辑闭环的观点。
• 面对一个稍微复杂的空白项目，如果不先问问 AI，你甚至不知道第一行代码该从哪里下笔。
• 你的思维变得越来越“平”，越来越像那个永远正确但毫无生气的标准答案。

《纽约时报》畅销书《五种财富》的作者Sahil Bloom 将这种症状称为 “AI Brain”（AI 大脑）。

这并不是说你变笨了，而是说你变钝了（Dull）。

就像一个长期坐轮椅的人，腿部肌肉必然会萎缩。当我们习惯了 AI 这种“认知轮椅”，我们大脑中负责深度思考、构建逻辑、处理混乱的那些神经连接，正在慢慢断开。

AI 消除了“摩擦”，但人类的智慧，恰恰诞生于“摩擦”之中。

摩擦的价值：为什么痛苦是必要的？

我们一直被教育要追求效率，要消除阻力。但在认知科学领域，这个逻辑是反的。

真正的学习和创造，发生于“First-pass Thinking”（第一遍思考）的挣扎中。

当你面对一个复杂的架构难题抓耳挠腮时，当你面对一张白纸试图构建文章结构感到挫败时，请珍惜这种痛苦。

这正是你的大脑在“举铁”，神经突触正在高强度地建立新的连接。这种不适感，是你正在突破认知边界的信号。

如果你在这个时刻按下了 AI 的生成键，它确实给了你一个完美的答案，就像剥好了的送到嘴边的虾肉。但你失去了什么？

你失去了咀嚼、消化、甚至感受饥饿的机会。你跳过了“构建心理模型”的过程，直接快进到了结果。

外包了痛苦，也就外包了成长的机会。

拯救大脑：4 条反直觉的“反内卷”法则

那么，我们该如何对抗这种“认知萎缩”？并不是要扔掉 AI 回归原始，而是要主动设计“认知摩擦”。

Sahil Bloom 基于个人洞察，为我们总结了 4 条适合技术人的自救法则：

法则一：拥抱“第一遍思考” (Embrace First-Pass Thinking)

原则： I write before I refine.（先写再润色，而不是先生成再修改。）

不要一上来就让 AI 写代码或写草稿。

强迫自己写出那个烂透了的初稿，强迫自己先在白板上画出架构图的草图。

因为 AI 只能基于概率生成“平均值”，只有你的“第一遍思考”才带有“方差”——也就是你的原创性（Originality）和个性。

下次写文档，不妨先自己写 300 字的大纲，再让 AI 补充；而不是让 AI 生成大纲，你来修改。

法则二：人为制造“认知摩擦” (Preserve Cognitive Friction)

原则： I sit with problems.（让问题飞一会儿。）

遇到难题，不要通过条件反射式地 Alt+Tab 切到 与大模型聊天的页面。

允许自己困惑，允许自己焦虑，允许自己在那里发呆 10 分钟。

这种“滞后”是必要的。它给了你的大脑后台进程运行的时间（思考脑启动）。很多深刻的洞察，往往是在你“卡住”的时候涌现的。

不妨设定一个“无 AI 时间窗口”。比如每天上午的头 2 小时，强制断开 AI 助手，只靠自己的大脑工作。

法则三：做少，但做深 (Do Less, But Deeper)

原则： One kick 10,000 times.（不怕千招会，只怕一招精。）

AI 让我们能做 100 件事：能写前端、能写后端、能画图、能剪视频。但每件事我们都只能做到 60 分的平庸水平。

既然 AI 把广度的成本降到了零，那么深度就成了唯一的护城河。

试试利用 AI 帮你处理那些琐碎的、低认知的杂事，然后把节省下来的精力，全部投入到那个 1% 的核心领域中去。钻研到连 AI 都无法回答的深度。

法则四：回归“物理世界” (Do More Human Things)

原则： Stay anchored.（保持锚定。）

AI 没有身体，没有痛感，没有疲惫。

人类的直觉、审美和同理心，建立在我们肉身的经验之上，这是 AI 永远无法模拟的底色。

动起来！去面对面交流，去感受代码运行在真实物理设备上的延迟，去用身体感受世界。这些“肉身经验”是你作为人类的最后防线。

小结：你的未来，取决于你拒绝让 AI 做什么

我们正在进入一个“分化”的时代。

• 一类人把 AI 当作拐杖，离了它就寸步难行，最终沦为算力的附庸。
• 另一类人把 AI 当作外骨骼，他们依然拥有强壮的肉体（核心思考力），AI 只是放大了他们的力量。

区别在于边界的划分。

Your future is defined by what you refuse to let AI do.
（你的未来，取决于你拒绝让 AI 做什么。）

请守住你的“思考领地”。

我可以让 AI 帮我优化代码，但我决不允许它替我设计架构；
我可以让 AI 帮我润色文字，但我决不允许它替我定义观点。

在这个充满“灰度”和“平庸”的 AI 生成世界里，请保持你大脑的“色彩”和“锋利(Sharp)”。

Don’t become dull.

你的“戒断”计划

读完这篇文章，你是否也意识到了自己对 AI 的过度依赖？如果让你现在关掉 AI 助手，你能独立完成手头的工作吗？你打算如何找回自己的“认知摩擦”？

欢迎在评论区立下你的 Flag，或者分享你的“人机边界”思考！让我们一起守护大脑的锋利。

如果这篇文章戳中了你的痛点，别忘了点个【赞】和【在看】，并转发给身边那些“沉迷 AI”的朋友，给他们提个醒！

深度实战：构建“以人为本”的 AI 工作流

在 AI 原生开发中，我们同样强调：User 必须是机长，AI 只是副驾驶。

如何在利用 AI 提效的同时，还能迫使自己进行深度的架构思考？

如何在 Spec-Driven Development (SDD) 中，保留人类的“第一遍思考”权利，让 AI 只做执行者？

欢迎关注我的极客时间专栏《AI原生开发工作流实战》。

在这里，我们不教你如何偷懒，我们教你如何利用 AI 进行更高维度的认知进化。

扫描下方图片二维码，开启你的进化之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – 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 的飞轮效应：

1. 你构建原子工具和平权能力。
2. 用户提出了你未预料到的需求。
3. Agent 组合工具完成了任务（或失败，揭示了工具缺口）。
4. 你观察模式，添加领域工具或专用 Prompt 来优化。
5. 重复上述过程。

然后，通过观察你的应用能处理领域内的开放式请求，来验证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）：

1. 词汇表 (Vocabulary)： create_note 工具教会了 Agent 你的系统中“笔记”是什么。
2. 护栏 (Guardrails)： 某些操作需要验证，不应完全交给 Agent 判断。
3. 效率 (Efficiency)： 将常用操作打包，提升速度和降低成本。

领域工具的规则： 它们应该代表用户视角的一个概念性动作。它们可以包含机械验证，但不要包含“做什么”或“是否做”的判断——这属于 Prompt。同时，默认保持原语可用，不要为了这种封装而关闭底层权限，除非有安全理由。

升级成为代码 (Graduating to Code)

有些操作因为性能或可靠性原因，需要从“Agent 编排”升级成为“优化代码”。

1. 阶段 1： Agent 在循环中使用原语（灵活，验证概念）。
2. 阶段 2： 添加领域工具（更快，但仍由 Agent 编排）。
3. 阶段 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. 版权所有.