我们为什么放弃了Dify,自己搭了一套Agent平台

发布日期：2026-08-31 17:23:53 浏览次数： 1805

作者：AI淘金热

微信搜一搜，关注“AI淘金热”

一个关于"天花板"的故事

大概一年前,我们和很多团队一样,用Dify快速搭起了第一版Agent系统。

它确实解决了从0到1的问题——不用自己写沙箱,不用自己写工具调用协议,拖拖拽拽就能上线一个能用的Agent。那段时间,团队都很满意。

直到有一天,我们需要给不同租户做更细粒度的资源隔离,需要让某个Skill在独立的运行环境里跑,需要一个更灵活的多Agent协作方式——才发现,低代码平台的"拖拽"背后,其实是一堵看不见的墙。它把工程细节都替你屏蔽掉了,连你想动手改的权利,也一并拿走了。

于是我们决定:自己搭一套。

这篇文章,想聊聊这一年里,作为架构师,我对"怎么设计一个Agent系统"这件事,想清楚的几层道理。

第一层道理:别停在"会说话"这个阶段

刚开始做Agent的人,几乎都会经历同一条路径:先琢磨怎么把prompt写得更精准,再琢磨怎么把知识和工具喂给模型,最后才会意识到——光有嘴,没有身体,Agent什么都干不成。

我把这条路径归纳成四个阶段:

Prompt Engineering,解决的是"怎么让模型听懂一句话";
Context Engineering,解决的是"怎么给模型喂对信息";
Harness Engineering,解决的是"怎么给模型搭一具能真正干活的身体";
Loop Engineering,解决的是"怎么让Agent学会自己迭代,而不是每次都要人推一把"。

大多数团队的困境,其实不是模型不够聪明,而是他们一直在优化"嘴巴",却从没给Agent搭过一具像样的"身体"。这具身体,才是决定Agent系统上限的地方。

第二层道理:隔离这件事,没有捷径可走

如果你的Agent系统要服务多个客户,"隔离"两个字听起来简单,做起来处处是坑。

我们最后落地的方案,是一套基于Kubernetes的沙箱架构:每个Skill跑在独立的虚拟环境里,避免互相污染依赖;轻量任务尽量共置在同一个Pod里,减少调度开销;而遇到重任务,就把它卸载到带资源限制的K8s Job里去跑——绝不让一个失控的任务拖垮整个系统。

这套东西最有意思的地方在于:官方的Agent SDK文档里,根本没提到怎么做K8s Job卸载这件事。所有的细节,都是我们自己一点点摸出来的。这大概是做基础设施架构最真实的处境——文档能告诉你"标准姿势",但真正生产级的稳定性,永远要靠自己在边界之外趟出一条路。

第三层道理:一个Agent,干不了所有的事

早期我们试过让一个Agent既负责聊天,又负责规划,又负责执行——结果可想而知:响应慢,逻辑绕,出了问题不知道是哪一环出的错。

后来我们把它拆成了两个角色:一个对话Agent,专门负责跟用户交互,要快、要轻、要能秒回;一个规划Agent,专门负责拆解复杂任务、调度执行,可以慢一点,但要想得深。对话Agent一旦识别出用户的需求需要多步骤才能完成,就把接力棒交给规划Agent。

这个分工听起来朴素,甚至有点像团队管理的常识——不该让一个人既接待客户又跑重活。但把这条常识真正落进架构里之后,你会发现**"响应速度"和"任务质量"这两件事,终于不用再互相妥协了**。

后来我们研究了几个主流的企业级Agent Harness框架——LangGraph、CrewAI、AutoGen,还有SAP Joule,发现大家最后不约而同地收敛到了相似的分层思路。这让我确信一件事:自研的价值,从来不是发明一套全新的范式,而是把这些已经被验证过的分层逻辑,按自己业务的节奏重新组装一遍。

第四层道理:知识层,也需要"进化"

我们的RAG系统,前前后后经历了三代演进。

第一代是最朴素的固定长度切块——简单,但代价是语义边界被硬生生切断,上下文丢了一大截。第二代升级成层级化切块,保留了文档的结构信息,但本质上还是"先检索、再拼接"这种被动模式。第三代是VL-RAG叠加Agentic RAG——不仅让检索具备视觉理解能力,更关键的是,把"要不要检索、检索什么"这个决策权,也交还给了Agent自己,而不是写死在一条固定的pipeline里。

还有一条我一直在关注的路线,叫Corpus2Skill——它的野心更大:不把知识库变成一堆向量,而是提炼成一棵层级化的技能树。这不是向量检索的一个补丁,而是一种完全不同的知识组织哲学。长远来看,它未必是RAG的补充,更可能是替代。

第五层道理:Skill值得被当成"产品"来对待

很多团队的Skill,说白了就是配置文件里的一段prompt模板——没有版本管理,没有输入输出规范,改一个字全靠人肉review,谁都不知道改动会不会牵一发动全身。

我们现在在做的,是把Skill真正当成一等公民来对待:搭建一个Skill workbench,让每个Skill都有清晰的输入输出契约;引入SDD(Spec-Driven Development)——先把规范写清楚,再基于规范生成实现,而不是反过来。

这条路走得并不轻松,像spec-kit这样的工具落地到真实场景时,总会冒出各种意料之外的适配问题。但我越来越确信一件事:当Agent系统的规模上去之后,真正卡住团队的,往往不再是模型能力,而是Skill的可维护性。这就像一家公司从十个人扩张到一千个人,真正决定天花板的,从来不是某个明星员工有多厉害,而是整套流程和规范撑不撑得住。