友好定价、专业客服支持、正版软件一站式服务提供
工作日：9:00-22:00
发布时间：2026-05-25
浏览次数：0
构建人工智能智能体时, 好多团队常常由于盲目地一心追求多智能体编排以及复杂推理，从而陷入到所谓的“过度设计”的困境之中, 最终致使基础任务都没办法稳定交付；针对这一整个行业普遍存在的毛病, 贝迪所提出的五层渐进式架构给出了一条切实可行的道路：先是从赋予语言模型基础工具的没有状态的起始点开始, 按照需求依次叠加记忆所具备的知识、自主学习的能力、多角色之间的协作还有生产级的基础设施，着重强调只有当上面一个层级明确出现失效的情况时, 才去引入新的复杂度，这样一种“从简单着手、一步步进行验证”的工程思维方式, 不但能够有效减少调试所需要的成本, 更是打造出真正可靠、能够不断演进的人工智能系统的最关键的地方。
我们是否能够察觉到, 众多团队于构建AI agent之际, 皆在犯下同一类错误呢？他们一开始便着手进行多agent编排, 开展自主推理循环，搭建复杂的基础设施，而后耗费数周时间去调试竟然连最为简单的任务都没办法完成的缘由。此类过度设计产生的问题在整个行业范围之内普遍存在着，致使大量项目在中途就宣告废止了。最近，我翻阅到一篇由Bedi所分享的文章，他阐述了一个观点, 此观点触动我的心弦。他觉得构建 AI agent 需遵循一项略显”难为情”的简易规则，即起始于最为简单之处, 然后循序渐进增添能力, 于每一个步骤均考察行为状态。这个观念貌似平常，实则揭示了软件工程的根本原理。
我于实际工作当中，也时常可见这般现象, 团队急切渴望展示技术实力，意图一步达成构建复杂 AI 系统之目标, 然而却陷入了没完没了的调试以及重构之中, 反倒那从最小可行产品起始，一步步去迭代的团队，最终交付了切实可用的产品，Bedi 在文章里面系统概括了构建（agent 化软件）的五个架构层级，分别是带工具的 agent、带存储和知识的 agent、带记忆和学习的 agent、多 agent 团队, 还有生产系统。他借助构建一个称作 Gcode 的轻量级编程 agent 的方式来演示每一个层级，这般循序渐进的方法论给我带来了极大的启发。
为什么大多数团队一开始就错了
在对这五个层级展开深入探讨以前，我要先说一说为何这种渐进式的方法具备那样的重要性。我留意到一种饶有趣味的现象, 在AI agent领域当中，技术门槛的降低居然致使了更多的过度设计情况出现。这是由于大语言模型使得构建agent看上去轻而易举，众多团队错误地认为只要堆积足够数量的功能，便能够造就出一个强大的系统。然而这种想法从本质上来说是不正确的。
软件工程存在着一条经典原则，即提前优化乃是万恶之源，在 AI agent 开发里这样的原则同样是适用的，过早引入复杂架构，不但增加了开发以及维护成本, 更为关键的是，其会将真正的问题所在给掩盖起来, 一旦你的 agent 无法完成任务, 极难去判断是架构设计层面的问题抑或是提示词方面的问题或者是工具选择的问题, 要是一开始从最简单版本着手，每次仅仅增添一种能力, 那么问题定位便会容易许多。
Bedi的五层架构是基于这种递进式思维构建的, 每一层都解决了上一层明确存在的问题, 并非预先设想可能出现的问题, 这种务实态度在飞速变化的AI领域格外重要，技术在快速演进，今天看似必要的复杂架构, 明天或许就会被更简单的方案替代，维持架构的灵活性与可演进性，远比一开始就追求完美更为重要。
Level 1：给 Agent 装上手脚
第一层的核心理念极为直白：不存在工具的agent仅仅是一个大语言模型，它具备推理能力，然而无法做成任何实际的事情, Tools（工具）乃是把LLM转变为agent的关键所在, Bedi于构建编程agent Gcode之际, 界定了最小可行工具集, 具体包括读取文件、写入文件、运行shell命令，此三个工具体现出一个编程agent的基础能力。
我极其赞同这个最小化的起始点, 许多人于设计agent之际，会一下子给它配置十几种乃至几十种工具，觉得工具越多能力越厉害，然而实际情形常常相反, 工具过多会致使agent在做出选择之时出错的, 它有可能会运用错误的工具, 也许会在多个相近工具之间犹豫不决，从认知负荷的层面去看，这恰似让一个人同时去学习二十种乐器，结果很可能是一种都学不善的。
于第一层，agent接收任务, 借由（编程工具集）开展编写、编辑以及运行代码这一活动。此过程全然乃是无状态之便, 每一回运行皆重新从起始处着手。Agent无可忆起前次之会话情形, 无法依循项目所用之约定, 除非你将这些信息粘贴于提示词里头。这听上去似颇为受限, 然而这恰恰正是其优势的根由所处。限制促使你留意核心功能，即查看：agent能否达成最基础的任务？工具的抽象是否合乎情理？提示词是否足够清晰明白？
在实际项目里头，我发觉众多貌似需要复杂架构的问题, 实际上运用第一层的简单 agent 就能够解决。很重要得一点是明确界定任务边界。要是你的任务的确简单又自包容, 就此而言, 一个无状态的 agent 搭配几个经由精心挑选的工具，全然能够做得让人称心。不要仅仅是因为在技术层面“能够”把事情做得更为复杂，就真的去那样操作。
Level 2：赋予 Agent 记忆和知识
运行时每次都得重新开始，所有的东西一律得放在上下文里, 这是第一层的最大问题，处理简单任务还行，可一旦需要多轮对话, 需要遵循特定规范，需要访问大量背景信息，这种无状态的方式就不行了，第二层靠添加会话存储和领域知识这两个关键解决了此问题。
它的价值体现于, 它把每个agent会话以及其中的每一次运行存储到了数据库里。这产生了两个关键益处。其一，能够借助聊天历史当作上下文，agent可以在其上下文窗口内纳入最近的N条消息, 从而知晓当下正在发生的情况。针对更长的会话而言, 你能够运行压缩算法去总结早期上下文，以使窗口聚焦于当前关键的内容。其二, 形成了完备的行为记录。并非全部事物都得传送给第三方追踪服务，将会话存储于自身的数据库内, 乃是领会agent所作所为、何时去做以及缘何这样做的最为简便的途径。你具备数据，能够对其进行查询、审计, 还能基于此构建仪表板。
的引进就处理好了另外一个重点难题。如今编程的 agent 仅仅可以瞧见代码库里面的文件，别的啥啥都瞧不见。它们没办法去接触你的架构准则、团队的设计决断、内部会议纪要, 或者某个 Slack 讨论组里阐释为何挑选 而非 的情况。这便是 亟待解决的问题。它为agent给予了一个能够进行搜索的存储库，其中存放的是所有关乎项目重要性却并非需要始终留存于上下文窗口之内的内容, 涵盖规范, RFP，运维手册，架构决策记录, 会议笔记, 团队对话。
关键洞察在此：大量有价值的上下文，存在于代码库之外。若团队上个月于会议里探讨过迁移策略, 那么在编程agent着手处理迁移工作之际，此上下文理应是可用的。要是半年前有人抉择使用库X而非库Y, agent应当能够在其准备删掉X重新起始之前，寻得此决策的缘由。我于实际工作当中，深切体会到了这一点。大量技术决策相关的背景信息, 分散于邮件之中，分布于文档里，还存在于聊天记录内，新近加入的团队人员，很难将其获取到，最终结果往往是，常常重复犯下同样的错误, 或者把先前经过深思熟虑得出的决策给推翻掉。
Bedi在实现当中运用了,将其当作向量数据库,以此支持混合搜索（）,这既能施行语义匹配又能够开展关键词匹配。这般的设计甚是巧妙,缘由在于不同情形的查询需求不一样的搜索策略。有时你得要精准匹配某个术语,有时你又得要领会语义相似性。Agent在编码之前会先去搜索,要是你的风格指南讲”采用 ”,agent会寻觅到并遵照它。这便是基础的RAG（检索增强生成）。
在何种情形下应当运用第二层呢，是当agent必须依照它于训练期间未曾见识过的标准行事之时，或者是当用户抱有多轮对话的期望之际。这乃是绝大多数内部工具的最优选择。我觉得好多企业级应用事实上仅停留在这一层便已足矣, 并不需要更为繁杂的功能。关键之处在于要清晰地辨识你的实际需求, 而并非是被新技术的耀眼光芒所蛊惑。
Level 3：Agent 开始学习和进化
从第二层朝着第三层的那种跳跃，是最为关键的一回飞跃，在第二层的时候codejock software，agent依照你给予它的规则行事，在第三层当中，它借助经验去学习规则，这种区分看起来好像挺微妙, 实际上却是根本性的，Bedi提出了一道简洁且有力度的标准，即第1000次交互理应比第1次交互更出色, 这便是学习的实质所在。
第三层引进了（学习机器）, Agent 获取了及两个工具，它自行判定什么值得记住, 即有效的编程模式, 要规避的错误, 用户偏好, 这些学习所得被存于一个单独的base（知识库）中, 且在日后的会话里被调用, 与此同时, （agent记忆）使agent能够随时间创建用户画像，即你偏爱的编程风格，你运用的框架, 你喜好的解释方式。
我觉着这一层面的设计理念尤为有趣，它并非单纯记录全部交互历程, 乃是促使智能体自行判定什么值得研习，这般选择性记忆更贴近人类之学习办法, 我们并非记住每一个细节实例, 而是抽取出模式原理以及偏好倾向，如此抽象本领使得智能体能够把经验推广到全新情境里, 并非仅仅是机械死记。
Bedi给出了个例子，是关于”两次会话测试”的。在第一次会话里，用户表达了对函数式编程风格的偏好，也就是不用类，要使用纯函数以及不可变数据。在第二次会话时, 当用户要求编写日志解析器，agent就得搜索它的学习记录, 找到函数式编程偏好, 然后写出函数式代码。这个测试很好地展示了学习的价值，即agent不需要每次都重新告知偏好, 它能够记住并应用。
当, agent反复为同一批用户提供服务, 且需随时间不断改进时，是应该使用第三层的时机。个人编程助手，具有共享学习的团队工具, 任何“照我们心仪的方式去做”极其重要的场景。我觉得这是AI agent真正开始彰显价值的层级。前两层更多属于效率工具, 而第三层开始拥有了个性化以及适应能力，使得它从工具转变为助手了。
就在我思索这一层内容之际, 脑海中浮现出了一个问题, 那就是：agent 的学习究竟应当存在边界局限之情状吗, 它是要去学习涵盖所有用户的各种偏好, 还是仅仅学习特定某些类型的偏好，如果用户所具有的这些偏好本身是属于错误的或者效果不佳效率低下的那样一种情况, 那 agent 到底是应该不加思考盲目地一味遵循, 还是要提出疑问进行质疑，诸如此类的这些问题并没有能够轻易得出答案来的那般简单情形，然而它们却明确地指向了一个层面更为深层的设计哲学要点, 那便是：我们内心期望 agent 去扮演的到底是怎样一种角色，是那种仅仅只会服从安排的执行者角色, 还是如同能够给予他人建议的顾问角色？
Level 4：多 Agent 协作的承诺与陷阱
偶尔来讲, 单单一个agent的确是不足够的。第四层会把职责分散于那些经由团队领导予以协调的专业化agent之间。Bedi所举的示例是具备直观性的：Coder承担编写代码的工作，有个体负责审查质量、观察bug以及遵循最佳实践情况，还有个体承担编写以及运行测试相关事宜。每一个agent都拥有清晰且明确的角色以及工具权限。留意一下特定的工具配置：将写文件、编辑文件还有运行shell的能力予以禁用，仅仅能够进行读取操作。这样的权限控制切实保证了agent只管去做其理应做之事。
从事多 agent 团队工作，在概念层面极具吸引力, 它模拟了人类团队的工作模式, 每个成员具备专长, 借助协作来达成复杂任务。于代码审查场景里，这般分工尤为自然, 即一人负责编写, 另一人进行审查，还有一人开展测试。然而, Bedi 在此给出了极为诚恳的告诫，如果多 agent 团队强大却无法预测。团队领导者乃是一个 LLM，负责做出委派决定性的行动事宜。有时它的委派表现出色codejock software，有时则不尽如人意。对于需求可靠性的生产系统来说，显式工作流要优于活力无限的团队。团队在有人类监督的场景中表现最好，人类可以审查输出。
这个警告具备相当的重要性，原因在于它彰显出多agent系统的核心要点, 即控制的丧失一情况, 一旦将决策权交付给个LLM协调者, 那么便会失去对于执行路径的精准控制，于演示期间, 此类动态性呈现出颇为酷炫之态，宛如 AI的”智能涌现”一般, 然而于生产环境里，不可预测性却是可靠性的巨大阻碍，个人觉得这是当下多 agent系统最为显著的局限所在。
用第四层的时机是何时呢？是当产生多个视角需求之际（代码审查便是绝佳实例），是当任务能自然被拆解成专家角色之时, 还是当构建交互式工具且人类能施行团队监督之时呢？我的看法更为保守：若不存在颇为明晰的缘由, 那么优先考量单个设计优良的 agent。多 agent 系统的复杂性所引发的成本颇高，唯有在收益显著超出成本之际才具付出的价值。
我打算补充些许个人的观察，于诸多展开多agent架构宣传的案例当中而言，实际赋予价值的时常并非是“多个agent”，而是“明确的职责分工”以及“结构化的工作流程”。此类益处虽在单agent架构里同样能够达成，然而那是经由不一样的方式达成。相较于促使多个agent展开动态协作，倒不如让一个agent依据明确定义好的步骤去开展工作, 且每一个步骤运用各异的工具或者提示词配置。这样的一种方法于可控性以及可调试性方面均更具优势。
Level 5：走向生产环境的最后一公里
第五层，乃是要把前四层转化成用于生产服务的运行时环境。你得从开发数据库进行升级，升至生产数据库，还要添加追踪, 并且要把所有内容当作 API 给暴露出来。Bedi 于此处的做法颇为务实：用和与替换和与, 从而获得真正的连接池、真正的备份、真正的并发访问能力。
它有着相当有意思的概念，它会把你的agent包装于一个应用里去，这个能提供内置Web UI的应用，还有会话管理以及追踪功能，像这种“拿来就能使用”的办法，极大地降低了把agent投入到生产时的门槛, 你并不需要亲自去搭建这一整套的基础设施, 仅仅只是将agent配置好之后, 它便能够帮你来处理剩余的部分，启用追踪（等于True）的话，会让你有能力去观察每一次的工具调用，每一回的知识搜索，每一个的委派决策, 而这对于调试生产方面的问题来讲是极其关键的。
什么时候应当去使用第五层呢，是在agent脱离你的笔记本电脑之际。存在多用户的情况，有着正常运行时间的要求，还有着需要对生产问题加以调试的场景。我觉得这一层的重要程度时常被低估了。许多团队于开发环境之中打造出了很棒的agent，然而在进行生产化的时候遭遇到了各种各样的问题, 包括性能、可扩展性、可观测性以及安全性。预先规划好这些非功能性需求, 相较于后期去打补丁可要容易得多了。
我要着重指出一个常常被人忽略的要点, 生产环境中的那个agent得需要运维。它可不是部署完之后就能够一劳永逸那般的。你得对它的表现加以监控, 收集用户反馈，定期对知识库进行更新, 调整提示词, 处理边缘情况。这是需要投入持续不断的人力以及时间之类的。所以在决定去构建生产级agent之前，要确保你是有资源可以用来维护它的。
最重要的建议：从简单开始
将Bedi的文章读完以后，我所获得的最大收获便是这样一条建议, 那就是从第一层着手，去构建出能够将问题解决的最为简单的agent，接着运行它, 查看它在何处遭遇失败，随后仅仅添加它所欠缺的那一项能力, 这听上去分明是十分简单的，然而在实际操作当中却是极难达成的，我们老是会被新技术以及新架构所带来的诱惑给吸引住, 从而想要一次性就构建出最为先进的系统。
大多数团队, 直接跳到第四层，只因多agent架构，在演示里看着很酷。而后他们耗费数月，调试协调失败的问题，然而这些问题，一个设计优良的单agent，加上好的指令，便能规避。这种过度设计的诱惑，在技术行业颇为常见, 可在AI agent领域，尤为危险，因为调试成本格外高。
试着将这五个层级去想象成，是能力以及复杂性所构成的层次结构。要记住，每一层都致使复杂性有所增加, 可复杂性是存在成本的。唯有在更简单的方法明确宣告失败之后, 才去付出这一成本。这种具备纪律性的方法不但能够让你以更快的速度交付可用的产品，而且还能够让你对每个能力的价值以及代价, 有着更为深入的理解。
我的个人看法是，那种渐进式手段的意义, 不光是在技术方面体现, 更是在认知方面凸显。当你起始于简易之时，你会被逼迫着切实去领会所面临问题的根本实质。你不能够借助复杂的架构去掩饰对相关问题的含混性认知。你得清晰明确地界定，这个智能体所要去解决的究竟是什么问题, 它需要具备怎样的能力, 怎样去证实它是否达成了目标。这些基础性问题的答案，要比任何看似夸张花俏的架构更为关键重要。
对人工智能飞快发展变化的领域而言, 维持架构的简易与灵活相较于追求尽善尽美更具价值。今日看似必需的繁杂功能，明日说不定就会被更为简易的办法所替代。相较于去构建一个复杂却脆弱的系统, 构建一个简单且能够不断发展的系统更为可取。这样的思维模式不止适用于人工智能智能体, 对一切软件开发皆适用。
最后我要讲，Bedi所提供的这个框架并非一种教条，而是用作指南的东西。你有可能会发觉你的场景要求不一样的层级划分, 或者是要跳过某些层级。重点在于明白每个能力的作用以及代价，接着依据你的具体需求做出明智的抉择。盲目去遵循任何框架都是存在危险的，然而完全忽略前人的经验同样是有危险的。在这两者之间寻找到平衡，才是优秀工程师所具备的特质。
如有侵权请联系删除！
官方公众号
Copyright © 2023 江苏优软数字科技有限公司 All Rights Reserved.正版sublime text、Codejock、IntelliJ IDEA、sketch、Mestrenova、DNAstar服务提供商
Copyright © 2023 江苏优软数字科技有限公司 All Rights Reserved.正版sublime text、Codejock、IntelliJ IDEA、sketch、Mestrenova、DNAstar服务提供商
13262879759
微信二维码