架构这事儿，别跟我扯那些虚的

最近圈里特时髦一种文章。Agent 要分主从，Skill 要模块化，协议要标准化，编排得走图——一套一套的，名词儿一个比一个唬人，分层一层比一层精致。看的人热血上头，恨不得连夜把手里跑得好好的系统推了重来。

我劝您先消停会儿。

这年头说话漂亮的人太多了，真做事的人太少。一个东西被吹得越邪乎，您越得多个心眼儿。

先说个事儿：模型这玩意儿，就是地基

现在流行一句话，叫”模型不再是瓶颈”。

听着挺解气是吧？仿佛模型已经被驯服了，剩下的全是上层建筑的事儿。真在生产里跑过几个月 Agent 的人，没一个敢说这话。同样一套提示词，同样一套工具，同样一套流程，把底下的模型从中等换成顶尖的，效果差出去能差一个数量级。

地基是地基，楼是楼。地基软，您楼盖得越高塌得越快。这不是什么深奥的道理，盖过房子的都懂。

那为什么这话还满天飞？因为有人指着这话吃饭呢。模型一被弱化，他们手里那套调度内核、Skill 资产、协议适配，立马就成了不可或缺的东西。手里有锤子的人，看世界全是钉子——这把戏老得不能再老了，换个时代换个名词，照样有人买账。

但话又说回来，只有强模型也是不够的。这是另一面，也得讲。

最近有研究者把 Claude Code 的源码拆开来看，发现一个挺有意思的数据：整套系统里，真正调用模型做决策的代码大概占百分之一点六，剩下的百分之九十八点四，全是围绕这个决策的”脚手架”——权限系统、上下文压缩、工具编排、检查点、会话存储、安全分类。这事儿很说明问题。模型是引擎，但车子能不能跑、跑得稳不稳、撞了能不能刹住，全靠围着引擎搭起来的那一大堆基础设施。

所以这事儿的真相是：模型决定上限，工程决定能不能上线。 这两头都不能含糊。哪头说”另一头不重要”，都是在卖东西。

多 Agent 协同：听着热闹，做着糟心

“主 Agent 调度，子 Agent 分工”——画在 PPT 上跟一支精锐部队似的，纪律严明，各司其职。

真做起来您就知道是怎么回事了。

每多一个 Agent 就是一个新的故障点。每一次跨 Agent 通信就是一次上下文损耗加歧义。一个任务跑一圈下来，Token 翻三五倍，延迟翻几倍，调试难度直接上一个台阶。出了问题您都不知道找谁——是调度 Agent 理解错了？是子 Agent 漏了信息？还是它们俩传话的时候掉链子了？跟破案似的。

Claude Code 里也有 subagent 机制，但您看人家怎么用的——是主循环遇到具体的、可隔离的子任务时，开一个干净的工作树，让子 Agent 在隔离环境里独立把那一小段干完，干完就退出。这是有边界的分工，不是”画一张组织架构图把任务切成五份”。前者解决具体问题，后者制造新的问题。

我跟您说实话：多 Agent 这套，只在特定复杂度之上才划算。 这个门槛比绝大多数人想的高得多。九成的业务，一个能力强的模型加几个趁手的工具，做几轮 ReAct 循环，齐活儿。够用，便宜，出问题还能查。

能不复杂就不复杂——这不是怂，这是有数。复杂度都是有代价的，代价往往三个月后才找上门。那时候您再回头拆，比当初不上还难受。

DAG 编排取代链式调用：别神化它

图编排在某些场景确实比线性调用强，这个我认。

但它被吹成”新一代执行引擎”，过了。

您去看那些真正跑得起来的 Agent 系统，包括 Claude Code，核心循环是什么？还是那个朴素的 ReAct——感知、思考、调用工具、看结果、再思考。一个 while 循环，简单得不能再简单。复杂的不是循环本身，是循环外面那一圈儿托底的东西：权限怎么管、上下文怎么压缩、工具怎么发现、出错了怎么回滚、会话怎么续上。

为啥不上复杂的图编排？因为模型本身就在动态做规划。您硬把它塞进一张固定的图里，反而把它的灵活性给框死了。模型变强一档，您那张图就得重画一遍——这种系统迭代起来非常痛苦。

图编排有它的位置——流程明确、分支可数、对一致性要求高的场景，比如审批流、数据清洗管线。模型自主循环也有它的位置——任务开放、路径不定、需要灵活判断的场景，比如改代码、做研究。各管一摊，谁也别想吃掉谁。

把图编排说成万灵药，是把锤子当成了一切。

协议这事儿：用，但别焊死

MCP 现在确实是 Agent 领域里少见的、被广泛采纳的开放协议。Claude Code 里能看到它，OpenAI 那边在用，开源社区也在跟。方向上没什么可争的。

但要说协议层已经”统一”了，早着呢。Agent 间通信、运行时管理这些更上层的东西，还在各家各做。您今天要是按某个还没成熟的协议做了深度耦合，明天可能就得返工。

聪明的做法是：用，但中间留一层薄薄的适配。 把协议当成一个还会变的接口，别当成不变的真理。这是工程上的基本常识——还在演进的东西，都得用抽象层隔开，不能直接焊死。

至于 Skill——这词儿现在被用得有点泛滥。Claude Code 里的 Skill 是个挺克制的东西：本质上就是一段写好的提示+一组关联工具+一些上下文资源，按需加载，不用就不占地方。它解决的是一个具体问题：怎么让 Agent 在不同场景下调用不同的”专业模式”，又不把所有东西都塞进系统提示里。

这事儿有用，但它不是什么”未来架构核心资产”。它就是个优雅的提示词工程包装，加上按需加载机制，仅此而已。把它拔到”竞争力终极形态”那种高度，是把一个工程技巧吹成了哲学。

真正该警惕的是什么

是把架构当信仰。

我见过太多项目，画出七八层精美的分层图，每层名字都响亮，每层职责都清晰。上线之后呢？真出问题的从来不是层不够多。是数据流不顺，是监控没到位，是评估根本没建，是成本算不明白。

架构图是给人看的，系统是给用户跑的。 这两件事经常被搞混。

具体到 AI 应用，有几个真问题，您画再漂亮的图都绕不开：

评估。 Agent 这玩意儿本来就不确定。今天跑得好，明天换个 Skill 换个模型，可能就退化了。怎么持续度量改完之后是涨是跌？这是现在最大的难题。没这套体系，所谓”热插拔 Skill”、“动态编排”全是赌博——您根本不知道改完是变好了还是变坏了。

权限与可控。 Agent 能改文件、能跑命令、能调外部服务——能力越强，出事的可能性越大。Claude Code 在这上面下了大功夫：七种权限模式，每个动作都过分类器，关键操作得用户拍板。这不是冗余，这是 Agent 要进生产环境的入场券。一个连权限边界都没想清楚的”未来架构”，就是个玩具。

成本。 多 Agent 加多层调度加多次 Skill 调用，单次成本可能是朴素方案的十倍五十倍。Demo 阶段无所谓，规模化之后这就是生死线。

延迟。 每多一层就是几百毫秒到几秒。用户的耐心是有边界的，这个边界比工程师想的要紧得多。

归因。 出了问题，是模型的锅、Skill 的锅、调度的锅、还是数据的锅？层越多，越查不清楚。运维要被逼疯。

数据闭环。 真正的长期竞争力来自反馈数据的积累——用户怎么用、哪儿失败了、怎么修正——这些信号被收上来、洗干净、用于迭代。把这事儿轻飘飘归到”长期记忆”四个字里，是严重低估它。

这几件事，没一件能靠”分层更精细”或者”协议更标准”解决。它们需要的是朴素的工程纪律：评估建好，成本算清，延迟测准，日志打全，数据闭环搭起来，权限边界划清楚。

听着土是吧？真做下来比那些漂亮架构难十倍。

我对未来真实的判断

未来几年，AI 应用里赢的，不会是架构画得最漂亮的那帮人。会是在底下这几件事上做得扎实的：

一是把业务摸透。 AI 是放大器，业务理解才是被放大的东西。理解浅，放大出来还是浅。架构再标准，套不到真问题上就是空转。

二是把模型摸熟。 知道这模型能干什么、干不了什么、什么时候会掉链子、得配什么样的提示和工具才能让它发挥。这是手艺活儿，不是套路。Claude Code 之所以好用，不是因为它架构多花哨，是因为做这东西的人对模型脾气摸得透。

三是评估闭环。 能快速验证一次改动是改进还是退步——这是 Agent 工程的核心能力。极朴素，极难做，真正做好的团队凤毛麟角。

四是克制。 能用简单方案就不上复杂的，能用一个 Agent 就不拆成五个，能用现成的就不自造轮子。Claude Code 的核心循环就是个 while 循环——这种克制本身就是一种本事。克制不是保守，是对代价有数。

五是基础设施的功夫。 那百分之九十八点四的脚手架不是白搭的。权限、上下文压缩、检查点、会话恢复、错误回滚、可观测性——这些活儿不光鲜，但缺一样系统就跑不稳。能在这些地方下笨功夫的团队，长期一定赢。

六是数据资产。 模型在涨，工具在涨，架构在涨——这些大家都能拿到。真正只属于您的，是您业务里跑出来的、被结构化沉淀下来的那些反馈数据。这才是您的护城河。

至于 Skill 化、协议化、模块化、分层化这些方向——大体是对的。能力解耦有价值，工具标准化长期看也是趋势。但这些就是软件工程几十年的常识在 AI 时代接着用，不是从天上掉下来的革命。把常识当常识用，比把常识吹成教条要靠谱得多。

最后说句

技术圈每隔几年就得造一次神。这次轮到 Agent 和 Skill 了。下次轮到啥，现在看不清，但肯定还会有。

每次造神的时候，最该做的不是追着浪头跑，是冷静问自己几句话：我的真问题是啥？这套方案解决了我的真问题吗？要付多少代价？万一错了，回退多难？

这几句话问明白，比您读十篇雄文管用。

技术这事儿，到头来，还是得老老实实做出来，不是漂漂亮亮讲出来。

讲得再好，跑不起来都是白扯。