企业官网建设流程全解析

大多数"agent 不靠谱"的判断,都把矛头指向了模型。
但真正的瓶颈,几乎从来不在那一层。

引子:一个被误诊的问题

我们都见过这样的场景:同一个底层模型,在聊天框里聪明得像个博士,接到一个真要"做事"的任务时却笨拙得像个实习生——文档格式乱、代码踩坑、流程漏步骤、工具用错。

第一反应大多是同一句话:“模型不够聪明。”

这句话听起来合理,但九成情况下是误诊。一个 agent 能不能把事做好,不是一个标量(智商),而是一个栈——好几层能力叠在一起,缺哪一层,整体就在哪一层失效。模型只是其中一层。

本文要讲的就是这个栈:Agent 能力栈。理解它的价值不在于多记几个术语,而在于当 agent 出问题时,你能知道该去修哪一层——而不是笼统地说"换个更大的模型"。

一、为什么需要一个"能力栈"的视角

把 agent 能力当作一个标量,会带来几个非常常见的误判:

• 把"输出格式不对"当成"模型不够聪明"——其实是做法规范没沉淀下来
• 把"事实错了"当成"模型在胡说"——其实是外部知识没接进来
• 把"卡住不动"当成"模型笨"——其实是没给它能动手的工具
• 把"风格不对"当成"模型理解不了"——其实是底座本身就不偏这种风格

每一种"症状"对应的是栈里不同的一层,修法、成本、速度完全不同。混在一起谈,基本只能得到"再试试更大的模型"这种没有杠杆的结论。

分层模型的真正价值,是把"agent 能力"这件事从模糊变成可工程化。

二、五层全景

┌────────────────────────────────────────────────────────┐ │ Goal 层(目标) : 这一次要达成什么? │ ← Prompt ├────────────────────────────────────────────────────────┤ │ Procedure 层(程序): 这类任务该怎么做才专业? │ ← Skill ├────────────────────────────────────────────────────────┤ │ Fact 层(事实) : 需要哪些外部信息? │ ← RAG / Search ├────────────────────────────────────────────────────────┤ │ Action 层(动作) : 我能对世界做什么? │ ← Tool ├────────────────────────────────────────────────────────┤ │ Weight 层(权重) : 本能反应、通用知识、风格 │ ← Fine-tuning └────────────────────────────────────────────────────────┘

一个 agent 处理一次任务,本质上是这五层同时被点亮、协同工作的过程。每一层各自回答一个不同的问题,各自有自己的修改机制和成本曲线。

下表是它们的速览,后面逐层展开:

三、逐层详解

3.1 Weight 层——本能

它回答的问题:模型不思考也会的事,长什么样?

它包含什么:

• 语言能力(语法、词汇、多语言理解与生成)
• 世界常识(水会沸腾、人有两只手)
• 推理直觉(基本因果、类比、数学感觉)
• 风格倾向(默认的语气、礼貌程度、表达节奏)
• 训练时学到的"做事品味"(写代码倾向用什么模式、解释问题时倾向从哪切入)

它的特性:

• 隐式:不写在某个文件里,分布在几十亿参数里
• 稳定:运行时不可改,要变只能重训或微调
• 通用:不针对任何具体任务,但任何任务都用到
• 慢更新:从训练到部署是月级周期

修改它的方式:Fine-tuning(SFT、RLHF、DPO 等)。这是改变模型"本能反应"的唯一手段——比如让通用模型变成"医疗对话风格"或"特定企业代码规范"。

类比:这是 agent 的"本能 / 直觉 / 性格"。一个人的母语反应、基本常识、思维习惯都属于这一层。

3.2 Action 层——手脚

它回答的问题:模型能对世界做什么?

它包含什么:函数调用、命令执行(bash/shell)、文件读写、网络请求、数据库查询、外部服务调用(MCP、第三方 SaaS)。

它的特性:

• 显式:每个动作有明确的 schema(名字、参数、返回值)
• 可枚举:agent 在每一刻都能列出"我现在能做哪些动作"
• 有副作用:这是和其他几层最大的区别——动作会改变世界状态(发邮件、删文件、扣款)
• 可观察:每次调用都有返回结果,可以基于结果决定下一步

修改它的方式:增加 / 减少可用工具,或者重新定义工具的 schema。

类比:这是 agent 的"手脚"。模型再聪明,如果只能输出文字、不能调工具,就只是个聊天机器人,不是 agent。

⚠️Tool 本身只是"能做什么"的目录,不是"该用哪个"的判断。后者需要上层(Procedure 层)来引导。给一个模型 100 个工具,如果没有 Skill 告诉它什么时候用哪个,它要么乱用,要么干脆不用。

3.3 Fact 层——外部知识

它回答的问题:为了完成任务,我需要哪些权重里没有、或者已经过时的信息?

它包含什么:私有文档(公司 wiki、个人笔记、合同)、实时信息(今天的股价、最新新闻、当前会议安排)、大规模知识库(法律条文、医学文献、产品手册)、用户自己的数据(邮件、聊天记录、订单历史)。

它的特性:

• 外部存储:存在数据库、向量库、文件系统、API 后面
• 按查询取:不预加载,根据当下任务取相关片段
• 快更新:数据变了,下一次查询就能拿到新的
• 不改变模型行为:只是把信息塞进上下文,让模型在这次回答里能引用

修改它的方式:RAG(向量检索)、Web search、数据库查询、知识图谱遍历。

类比:这是 agent 的"参考资料柜"。一个律师再厉害,办具体案子也要翻法条;模型再聪明,处理你公司的具体情况也要查你的文档。

这一层经常被和 Procedure 层混淆。区别在于:Fact 回答"是什么 / 有什么数据";Procedure 回答"在这种情况下应该怎么做"。"公司 2024 财报数字"是 Fact,"如何撰写一份符合公司格式规范的财报摘要"是 Procedure。

3.4 Procedure 层——做事方式

它回答的问题:面对这一类任务,专业的做法是什么?

它包含什么:工作流程(先做什么、再做什么、什么情况下分支)、工具选择(同样能完成的任务,哪个最稳)、输出规范(格式、命名、目录结构)、常见陷阱(哪些坑、怎么避、踩了怎么办)、决策树、反模式(明明能做但不要做的事)。

它的特性:

• 任务类型相关:不是"哪一次任务",而是"哪一类任务"
• 环境相关:同一类任务在不同环境下做法不同(同样是发邮件,公司内网 vs 公网完全不同)
• 可沉淀:专家做事的隐性知识,可以被写下来传给新人(或模型)
• 可演进:踩了新坑就更新,不需要重训模型

修改它的方式:Skill——文件系统上可寻址、可发现、按需加载的程序性知识包。

类比:这是 agent 的"操作手册 / 行业 know-how / 师傅传授的诀窍"。一个新人和一个老兵的区别,大部分就在这一层——不是更聪明、不是知道更多事实、不是工具更多,而是面对具体情况知道该怎么做。

3.5 Goal 层——意图

它回答的问题:这一次,我要达成什么?

它包含什么:任务描述、约束条件、偏好风格、上下文背景。

它的特性:

• 一次性:这次任务结束就过期
• 个性化:每个用户、每次任务都不同
• 易变:对话中可以随时调整、补充、否决前面的目标

修改它的方式:Prompt——用户当下写、当下改。

类比:这是 agent 的"今天接到的工单"。

四、五层的"经济学"

分层不只是分类游戏。每一层的修改成本和迭代速度差异巨大,这直接决定了工程上该先动哪一层。

修改成本 迭代速度 ↑ ↓ │ Weight层 │ 月级,要训练 │ Action层 │ 天级,要写代码 │ Fact 层 │ 小时级,要建索引/接 API │ Procedure │ 分钟级,改 Markdown │ Goal 层 │ 秒级,改 prompt ↓ ↑

这张图的含义是:

• 遇到问题先从最上层修起。能用 prompt 解决就别写 Skill,能写 Skill 就别加工具,能加工具就别微调。这不是偷懒,是用最低成本解决问题的工程直觉。
• 上层修不动了再动下层。如果发现同一类问题每次都要写一大段 prompt,说明该把这段沉淀成 Skill;如果发现 Skill 里要反复手动指挥模型做同一个动作,说明该把这个动作做成 Tool。
• 下层稳定性要高于上层。Weight 一年改几次,Tool 一月改几次,Skill 一周改几次,Prompt 一秒改一次——越往下,越要追求稳定;越往上,越要追求灵活。

这是 agent 工程里非常重要的一条直觉:让易变的留在上层,让稳定的沉到下层。

五、一个完整任务的层级流转

抽象讲完,看具体的。

用户说:“帮我把这份 PDF 报告整理成一份给客户看的 Excel 摘要。”

Goal 层(Prompt) ↓ "整理 PDF → Excel,面向客户" Procedure 层(Skill) ↓ 路由到 pdf-reading + xlsx-cleaner + client-facing-style ↓ "先诊断 PDF 类型 → 提取表格 → 按客户阅读习惯重排 → 加封面" Fact 层(RAG / Read) ↓ 读这份具体 PDF 的内容,获取它特有的数据 Action 层(Tool) ↓ 调 bash 跑 pdfplumber、调 create_file 写 Excel Weight 层(底座) ↓ 用预训练学到的语言能力组织文本、用通用编程能力写代码

每一层缺了都不行:

• 缺Goal,不知道做什么
• 缺Procedure,知道大概但做得不专业(可能用错库、忘记诊断步骤、输出格式不规范)
• 缺Fact,不知道这份具体 PDF 里有什么
• 缺Action,只能描述结果不能产出文件
• 缺Weight,根本不懂 PDF / Excel 是什么

一个真正可靠的 agent,不是某一层格外强,而是五层都在线。

六、按层调试:Agent 出问题时该怎么诊断

分层模型最直接的实战价值,是它给了你一份"诊断清单"。下次 agent 出问题,按这个顺序问:

1. 是 Goal 层的问题吗?
用户的 prompt 表达清楚了吗?约束写全了吗?如果不写也能做对,那不是 Goal 问题;如果改一下 prompt 就修好了——问题就在这一层,别再往下挖。

2. 是 Procedure 层的问题吗?
模型知道大方向但做得不专业?用错了库?输出格式不规范?忘了关键步骤?——这类问题几乎都是 Procedure 层的,加一个 Skill 或改一下 Skill 内容就能修。

3. 是 Fact 层的问题吗?
模型说的话整体合理但具体数字 / 名字 / 时间不对?这是它没拿到对的外部信息——检查 RAG 接没接、搜索结果质量、知识库覆盖度。

4. 是 Action 层的问题吗?
模型卡住了、说"我没法做这件事"、或者绕了个奇怪的弯子?八成是缺工具,或者工具描述写得让它不敢用。

5. 是 Weight 层的问题吗?
前面四层都查过了,问题仍然在?可能是底座本身就不擅长这类任务——考虑换模型,或者微调。

这个顺序背后是一个朴素的原则:先怀疑最容易修的那一层。九成 agent 问题在前三层就能解决,真正需要动 Weight 的极少。

七、几个常见误区

"模型不够聪明"几乎从来不是真问题

绝大多数 agent 失败,在你按上面那张诊断清单走完之前,根本轮不到模型。把所有问题都归因到"模型",等于放弃了所有工程杠杆。

各层不是替代关系,是协作关系

经常听到"用了 RAG 就不用 fine-tuning"“有了 Skill 就不需要 Tool”——这都是把同层之间的选择,误当成跨层之间的替代。RAG 在 Fact 层,fine-tuning 在 Weight 层,它们解决的根本就是不同问题。Skill 在 Procedure 层,Tool 在 Action 层,同样如此。它们之间不是 OR,是 AND。

上层修不动了,再考虑动下层

工程上一个最容易犯的错误,是听到一个新需求就直接想"要不要微调一下模型"。绝大多数时候答案是不要——先在 Goal 层试,不行去 Procedure 层加 Skill,再不行才考虑 Action / Fact / Weight。越下层动作,越贵、越慢、越难回头。

上层不能完全代替下层

反过来也不能贪便宜。一个常见的反模式是:用一段超长 prompt 去模拟 Skill 该做的事,或者用 Skill 去做 Tool 该做的事(让 Skill 在 Markdown 里"描述"调用 API,而不是让模型真去 invoke)。短期能跑,长期会塌——每一层都有它最适合的事,逼它干别层的活,代价会以另一种形式回来。

结语

如果用一句话概括这篇文章:

Agent 不是一个"更聪明的模型",而是一个由五层能力叠加而成的系统:Weight 给本能,Action 给手脚,Fact 给资料,Procedure 给方法,Goal 给方向。

这个分层不是凭空发明的——它本来就客观存在,只是过去我们没用这套语言去看它。当 prompt 工程、RAG、tool calling、Skill、fine-tuning 这些技术各自发展时,我们容易陷在某一层里争论"哪个更重要"。但站在能力栈的视角看,它们根本不在同一个维度上,重要性不是排他的,而是叠加的。

真正决定一个 agent 走多远的,不是某一层做到极致,而是五层都在线、五层都协调。

而所谓"agent 工程师"的核心能力,可能就一句话:

在合适的层,做合适的事。

知道哪个问题该用 prompt 解决,哪个该用 Skill 沉淀,哪个该加工具,哪个该接 RAG,哪个才真到需要微调的程度——这种判断力,比任何单点技术都更稀缺,也更难取代。