构建 AI Agent 时，许多团队常因盲目追求多 Agent 编排与复杂推理而陷入“过度设计”的泥潭，导致基础任务都无法稳定交付；针对这一行业通病，Ashpreet Bedi 提出的五层渐进式架构提供了一条务实路径：从赋予 LLM 基础工具的无状态起点出发，按需依次叠加记忆知识、自主学习、多角色协作及生产级基础设施，强调仅在上一层级明确失效时才引入新复杂度，这种“从简单开始、逐步验证”的工程思维，不仅能有效降低调试成本，更是打造真正可靠、可演进 AI 系统的关键所在。

你有没有发现，很多团队在构建 AI agent 时都在犯同一个错误？他们一上来就搞多 agent 编排、自主推理循环、复杂的基础设施，然后花几周时间调试为什么最简单的任务都无法完成。这种过度设计的问题在整个行业里普遍存在，导致大量项目半途而废。最近我读到 Ashpreet Bedi 分享的一篇文章，他提出了一个让我深有感触的观点：构建 AI agent 应该遵循一个简单得有些”丢人”的原则——从最简单的开始，逐步增加能力，在每一步都验证行为。这个理念看似平淡无奇，却道出了软件工程的本质。

我在实际工作中也经常看到这种现象。团队急于展示技术实力，想要一步到位构建出复杂的 AI 系统，结果却陷入了无休止的调试和重构。反而是那些从最小可行产品开始，一步步迭代的团队，最终交付了真正可用的产品。Ashpreet Bedi 在文章中系统地总结了构建 agentic software（agent 化软件）的五个架构层级：带工具的 agent、带存储和知识的 agent、带记忆和学习的 agent、多 agent 团队，以及生产系统。他通过构建一个名为 Gcode 的轻量级编程 agent 来演示每个层级，这种循序渐进的方法论对我启发很大。

为什么大多数团队一开始就错了

在深入探讨这五个层级之前，我想先谈谈为什么这个渐进式的方法如此重要。我观察到一个有趣的现象：在 AI agent 领域，技术门槛的降低反而导致了更多的过度设计。因为大语言模型让构建 agent 看起来很容易，很多团队误以为只要堆砌足够多的功能，就能得到一个强大的系统。这种想法从根本上就是错误的。

软件工程有一个经典原则：提前优化是万恶之源。在 AI agent 开发中，这个原则同样适用。过早地引入复杂架构，不仅增加了开发和维护成本，更重要的是，它会掩盖真正的问题所在。当你的 agent 无法完成任务时，你很难判断是架构设计的问题，还是提示词的问题，还是工具选择的问题。而如果你从最简单的版本开始，每次只添加一个能力，那么问题定位就会容易得多。

Ashpreet Bedi 的五层架构正是基于这种递进式的思维。每一层都解决了上一层明确存在的问题，而不是预先设想可能出现的问题。这种务实的态度在快速变化的 AI 领域尤其重要。技术在快速演进，今天看起来必要的复杂架构，可能明天就被更简单的方案取代了。保持架构的灵活性和可演进性，远比一开始就追求完美重要。

Level 1：给 Agent 装上手脚

第一层的核心理念非常直接：没有工具的 agent 只是一个大语言模型。它能推理，但做不了任何实际的事情。Tools（工具）是将 LLM 转变为 agent 的关键。Ashpreet Bedi 在构建编程 agent Gcode 时，定义了最小可行工具集：读取文件、写入文件、运行 shell 命令。这三个工具构成了一个编程 agent 的基础能力。

我特别认同这个最小化的起点。很多人在设计 agent 时，会一口气给它配备十几种甚至几十种工具，认为工具越多能力越强。但实际情况往往相反。工具太多会导致 agent 在选择时犯错，它可能会用错误的工具，或者在多个相似工具之间摇摆不定。从认知负荷的角度看，这就像让一个人同时学习二十种乐器，结果可能是一种都学不好。

在第一层，agent 接收任务，使用 CodingTools（编程工具集）来编写、编辑和运行代码。这个过程是完全无状态的，每次运行都从零开始。Agent 无法回忆之前的会话，无法遵循项目约定，除非你把这些信息粘贴到提示词中。这听起来很受限，但这恰恰是它的优势所在。限制迫使你专注于核心功能：agent 能否完成最基本的任务？工具的抽象是否合理？提示词是否清晰？

我在实际项目中发现，很多看似需要复杂架构的问题，其实用第一层的简单 agent 就能解决。关键在于明确定义任务边界。如果你的任务确实简单且自包含，那么一个无状态的 agent 配合几个精心选择的工具，完全可以胜任。不要因为技术上”可以”做得更复杂，就真的去做。

Level 2：赋予 Agent 记忆和知识

第一层的最大问题是什么？每次运行都要重新开始，所有东西都必须放在上下文中。这在处理简单任务时还能接受，但当你需要多轮对话、需要遵循特定规范、需要访问大量背景信息时，这种无状态的方式就不够用了。第二层通过两个关键添加解决了这个问题：session storage（会话存储）和 domain knowledge（领域知识）。

Storage 的价值在于它保存了每个 agent 会话及其中的每次运行到数据库中。这带来两个重要好处。一是可以将聊天历史作为上下文，agent 能够包含最近的 N 条消息在其上下文窗口中，知道正在发生什么。对于更长的会话，你可以运行压缩算法来总结早期上下文，保持窗口专注于当前重要的内容。二是创建了完整的行为记录。不是所有东西都需要发送给第三方追踪服务，把会话存在自己的数据库里是理解 agent 做了什么、何时做的、为什么做的最简单方式。你拥有数据，可以查询它、审计它、在上面构建仪表板。

Knowledge 的引入则解决了另一个关键问题。今天的编程 agent 只能看到代码库中的文件，别的什么都看不到。它们无法访问你的架构规范、团队的设计决策、内部会议记录，或者某个 Slack 讨论串里解释为什么选择 Postgres 而不是 DynamoDB 的内容。这就是 knowledge 要解决的问题。它给 agent 提供了一个可搜索的存储库，里面是所有对项目重要但不需要一直待在上下文窗口中的内容：规范、RFP、运维手册、架构决策记录、会议笔记、团队对话。

这里有个关键洞察：大量有价值的上下文存在于代码库之外。如果你的团队上个月在会议中讨论了迁移策略，那么当编程 agent 处理迁移工作时，这个上下文应该是可用的。如果半年前有人决定使用库 X 而不是库 Y，agent 应该能够在它准备删掉 X 重新开始之前找到这个决策的理由。我在实际工作中深刻体会到这一点。很多技术决策的背景信息散落在邮件、文档、聊天记录中，新加入的团队成员很难获取，结果常常重复犯同样的错误或者推翻之前深思熟虑的决策。

Ashpreet Bedi 在实现中使用了 ChromaDb 作为向量数据库，支持混合搜索（hybrid search），既能进行语义匹配也能进行关键词匹配。这种设计很聪明，因为不同类型的查询需要不同的搜索策略。有时你需要精确匹配某个术语，有时你需要理解语义相似性。Agent 在编码前会先搜索 knowledge，如果你的风格指南说”使用 snake_case”，agent 会找到并遵循它。这就是基础的 Agentic RAG（检索增强生成）。

什么时候应该使用第二层？当 agent 需要遵循它训练时没见过的标准，或者当用户期望多轮对话时。这是大多数内部工具的最佳选择。我认为很多企业级应用其实停留在这一层就足够了，不需要更复杂的功能。关键是要清楚地识别你的实际需求，而不是被新技术的光环所迷惑。

Level 3：Agent 开始学习和进化

从第二层到第三层的跳跃是最重要的一次飞跃。在第二层，agent 遵循你给它的规则。在第三层，它从经验中学习规则。这个区别看似微妙，实则根本。Ashpreet Bedi 提出了一个简洁有力的标准：第 1000 次交互应该比第 1 次交互更好。这就是学习的本质。

第三层引入了 Learning Machine（学习机器）。Agent 获得了 save_learning 和 search_learnings 两个工具，它自己决定什么值得记住：有效的编程模式、要避免的错误、用户偏好。这些学习成果被存储在一个独立的 knowledge base（知识库）中，并在未来的会话中被调用。同时，agentic memory（agent 记忆）让 agent 能够随时间构建用户画像：你偏好的编程风格、你使用的框架、你喜欢的解释方式。

我觉得这一层的设计哲学特别有意思。它不是简单地记录所有交互历史，而是让 agent 自主判断什么值得学习。这种选择性记忆更接近人类的学习方式。我们不会记住每一个细节，而是提取出模式、原则和偏好。这种抽象能力让 agent 能够将经验泛化到新的情境中，而不只是死记硬背。

Ashpreet Bedi 给出了一个”两次会话测试”的例子。在第一次会话中，用户表达了对函数式编程风格的偏好——不用类，使用纯函数和不可变数据。在第二次会话中，当用户要求编写日志解析器时，agent 应该搜索它的学习记录，找到函数式编程偏好，并写出函数式代码。这个测试很好地展示了学习的价值：agent 不需要每次都重新告知偏好，它能够记住并应用。

什么时候应该使用第三层？当 agent 反复服务同一批用户，并且应该随时间改进时。个人编程助手、具有共享学习的团队工具、任何”按我们喜欢的方式做”很重要的场景。我认为这是 AI agent 真正开始展现价值的层级。前两层更多是效率工具，而第三层开始具备了个性化和适应能力，这让它从工具变成了助手。

我在思考这一层时想到一个问题：agent 的学习应该有边界吗？它应该学习所有用户偏好，还是只学习某些类型的偏好？如果用户的偏好本身是错误的或低效的，agent 应该盲目遵循还是提出质疑？这些问题没有简单答案，但它们指向了一个更深层的设计哲学：我们希望 agent 扮演什么角色——服从的执行者，还是能够提供建议的顾问？

Level 4：多 Agent 协作的承诺与陷阱

有时候一个 agent 确实不够。第四层将职责分散到由团队领导协调的专业化 agent 之间。Ashpreet Bedi 的示例很直观：Coder 负责编写代码，Reviewer 负责审查质量、bug 和最佳实践，Tester 负责编写和运行测试。每个 agent 都有明确的角色和工具权限。注意 Reviewer 的工具配置：禁用了写文件、编辑文件和运行 shell 的能力，只能读取。这种权限控制确保了 agent 只做它应该做的事。

多 agent 团队在概念上很吸引人。它模仿了人类团队的工作方式，每个成员有专长，通过协作完成复杂任务。在代码审查场景中，这种分工特别自然：一个人写，另一个人审，第三个人测试。但 Ashpreet Bedi 在这里给出了一个非常诚实的警告：多 agent 团队强大但不可预测。团队领导是一个 LLM，在做委派决策。有时它委派得很好，有时不行。对于需要可靠性的生产系统，显式工作流优于动态团队。团队在有人类监督的场景中表现最好，人类可以审查输出。

这个警告很重要，因为它道出了多 agent 系统的核心问题：控制的丧失。当你把决策权交给一个 LLM 协调者时，你就失去了对执行路径的精确控制。在演示中，这种动态性看起来很酷，像是 AI 的”智能涌现”。但在生产环境中，不可预测性是可靠性的大敌。我认为这是当前多 agent 系统最大的局限所在。

什么时候应该使用第四层？当你需要多个视角时（代码审查是完美例子），当任务自然分解为专家角色时，或者当你构建交互式工具、人类可以监督团队时。我的观点更加保守：除非你有非常明确的理由，否则优先考虑单个设计良好的 agent。多 agent 系统的复杂性成本很高，只有在收益明显大于成本时才值得付出。

我想补充一点我的观察。在很多宣传多 agent 架构的案例中，真正带来价值的往往不是”多个 agent”，而是”明确的职责分工”和”结构化的工作流程”。这些好处在单 agent 架构中同样可以实现，只是方式不同。与其让多个 agent 动态协作，不如让一个 agent 按照明确定义的步骤工作，每个步骤使用不同的工具或提示词配置。这种方法在可控性和可调试性上都更胜一筹。

Level 5：走向生产环境的最后一公里

第五层是将前四层转变为生产服务的运行时环境。你需要从开发数据库升级到生产数据库，添加追踪，并将所有内容作为 API 暴露出来。Ashpreet Bedi 在这里的做法很务实：用 PostgreSQL 和 PgVector 替换 SQLite 和 ChromaDb，获得真正的连接池、真正的备份、真正的并发访问能力。

AgentOS 的概念很有意思。它将你的 agent 包装在一个 FastAPI 应用中，提供内置的 Web UI、会话管理和追踪功能。这种”开箱即用”的方法大大降低了将 agent 投入生产的门槛。你不需要自己搭建整套基础设施，只需配置好 agent，AgentOS 就能帮你处理其余部分。启用追踪（tracing=True）让你能够观察每个工具调用、每次知识搜索、每个委派决策，这对于调试生产问题至关重要。

什么时候应该使用第五层？当 agent 离开你的笔记本电脑时。多用户、正常运行时间要求、需要调试生产问题的场景。我认为这一层的重要性常被低估。很多团队在开发环境中做出了很棒的 agent，但在生产化时遇到了各种问题：性能、可扩展性、可观测性、安全性。提前规划这些非功能性需求，比后期打补丁要容易得多。

我想强调一个常被忽视的点：生产环境的 agent 需要运维。它不是部署后就能一劳永逸的。你需要监控它的表现、收集用户反馈、定期更新知识库、调整提示词、处理边缘情况。这需要投入持续的人力和时间。所以在决定构建生产级 agent 之前，确保你有资源来维护它。

最重要的建议：从简单开始

读完 Ashpreet Bedi 的文章，我最大的收获是这条建议：从第一层开始。构建能够解决问题的最简单 agent。运行它，看它在哪里失败，然后只添加它缺失的那个能力。这听起来很简单，但在实践中很难做到。我们总是被新技术、新架构的诱惑所吸引，想要一次性构建出最先进的系统。

大多数团队直接跳到第四层，因为多 agent 架构在演示中看起来很酷。然后他们花几个月时间调试协调失败的问题，而这些问题一个设计良好的单 agent 加上好的指令就能避免。这种过度设计的诱惑在技术行业很普遍，但在 AI agent 领域尤其危险，因为调试成本特别高。

把这五个层级想象成能力和复杂性的层次结构。记住，每一层都增加了复杂性，而复杂性是有成本的。只在更简单的方法明确失败后才付出这个成本。这种纪律性的方法不仅能让你更快地交付可用的产品，还能让你更深入地理解每个能力的价值和代价。

我的个人观点是，这种渐进式方法的价值不仅在于技术层面，更在于认知层面。当你从简单开始时，你被迫真正理解问题的本质。你不能用复杂架构来掩盖对问题的模糊认识。你必须清楚地定义：这个 agent 要解决什么问题？它需要什么能力？如何验证它是否成功？这些基础问题的答案，比任何花哨的架构都重要。

在快速变化的 AI 领域，保持架构的简单和灵活比追求完美更有价值。今天看起来必要的复杂功能，明天可能就被更简单的方案取代了。与其构建一个复杂但脆弱的系统，不如构建一个简单但可演进的系统。这种思维方式不仅适用于 AI agent，也适用于所有软件开发。

最后我想说，Ashpreet Bedi 提供的这个框架不是教条，而是指南。你可能会发现你的场景需要不同的层级划分，或者需要跳过某些层级。关键是理解每个能力的作用和代价，然后根据你的具体需求做出明智的选择。盲目遵循任何框架都是危险的，但完全忽视前人的经验也同样危险。在两者之间找到平衡，才是优秀工程师的特质。