企业官网建设流程全解析

“智能体来了”这四个字，我最近听得耳朵起茧。可真的翻过车之后，我才愿意承认：把它当人生捷径的人，最后都会被现实按在地上摩擦。我一度觉得，只要把需求丢给 agent，写周报、查资料、写 PRD、跑数学建模都能交给它，自己坐等答案就行。结果呢？demo 永远比想象中漂亮，落地之后全是坑。撕掉“人生捷径”这层滤镜，反而看清了智能体真正的价值——它不是替你选择，而是替你执行那些已经想清楚的重复劳动。这篇文章不是概念科普，是我从“智能体搭建-踩坑-复盘-再搭建”这条路上攒下来的实操记录。如果你正准备搭自己的第一个智能体、准备智能体面试，或者已经在生产环境里被 agent 坑过，这篇应该对你有用。

1. 别急着喊“取代”，先看懂智能体到底动了哪块蛋糕

1.1 从“会聊天”到“会干活”：智能体和聊天机器人差在哪

很多同事问我，智能体和之前的聊天机器人有什么区别。我一般用一个比方：聊天机器人是动嘴皮子的顾问，智能体是带手带脚的执行者。

传统聊天机器人把用户问题映射到一个固定答案，本质上是个“问答检索器”。就算接上大模型，它也只是把话说得更自然，并不会真的去查数据库、调接口、改文档。智能体不一样，它把“理解问题、拆解计划、调用工具、检查结果、继续迭代”这一整条链路串了起来。你让它“分析这个区域上季度销售波动原因并写成一页汇报”，它不会只给你一段含糊其辞的话，而是会先去查销售库，把数据拉出来做对比，找出异常月份，再生成一份报告，甚至顺手把报告保存到指定文件夹。

这个差别在工程上非常关键。Agent 的核心是“循环”：模型提出行动、系统执行行动、观察结果、再提出下一步行动。ReAct 这类范式看着简单，但真正落地时，工具定义、状态管理、异常处理、停止条件，每一个环节都可能让整个循环变成“嘴巴上的巨人、行动上的傻子”。

1.2 为什么这次不是概念炒作

这两年智能体被反复提起，一个重要原因是基础设施终于对上了。模型本身开始支持稳定的工具调用（function calling），RAG 检索的工程方案也成熟了，外部工具和 API 的标准化程度比以前高很多。换句话说，模型不再是“只能聊天”的玩具，而是真的可以成为工作流里的一环。

还有一个信号让我印象很深：业内有个共识，2026 年是工业智能体从概念演示走向工程化落地的分水岭。这句话不是随便说说的，背后其实是数据、工具、评估三个链路开始能对上。前几年大家做 demo，都拿几个精心挑选的问题展示“哇，它自己能上网搜答案”。但真到生产环境，老板会问“你的准确率是多少”“它乱答怎么办”“一个任务跑多久、多少钱”。这些问题，不是靠更长的 prompt 能解决的，而是要靠工程体系去控制。从社区讨论也能看出来，Dify、Coze 这类平台把流程编排门槛降下来了，agno 这类轻量框架让开发者可以快速做代码级定制，DeepSeek 也公开过把“观察-行动-反馈”循环接入训练的方法。这说明智能体正在从“靠提示词碰运气”变成“可训练、可度量、可优化”的工程产物。

2. 撕掉“人生捷径”后，我重新拆解智能体项目的四块基石

2.1 问题定义：不是所有场景都适合做智能体

我第一个犯的错，就是拿到什么需求都想塞给智能体。后来复盘才发现，很多需求根本不适合。

适合智能体的场景，一般有三个特征：第一，任务频繁重复，但每次都需要结合不同数据做判断；第二，判断过程依赖非结构化信息，比如文档、对话记录、页面内容；第三，即使答案出错了，也有人类在流程里兜底，不会直接造成不可逆后果。销售智能体就是一个典型例子——它可以帮助销售根据历史客户记录生成跟进建议，但真正谈价格、签合同这类高风险动作，还是得人来做。

不适合的场景也很有规律：需要深度专业知识且错误代价极高的决策、只发生一两次无法积累经验的冷门任务、以及外部信息严重缺失的问题。比如公司制度条例学习助手，可以让员工快速查到“年假怎么休”“报销流程是什么”，并且给出引用条款；但如果让智能体直接判“这个 case 能不能报销”，一旦数据不完整，它会把规则读歪，这就不合适了。

我在项目启动前一定会做一道筛选题：如果这个问题无法被一个实习生用半小时检索资料解决，那么也别指望智能体能一步到位。智能体不是许愿机，它只是把“实习生能干但不想干”的活自动化了。

2.2 技术底座：模型、RAG、工具调用怎么搭配

智能体项目里，我最先关注的是模型选型。不是参数越大越好，而是看它是否支持稳定的工具调用和较长的上下文管理。一个不能稳定输出结构化工具参数的模型，会让 agent 频繁“手滑”，明明该查表却自己编一个数字出来。

然后是 RAG。它的作用，是把私有知识装进系统里，但很多人把 RAG 想得太简单了。向量检索就像在一个超大图书馆里找书，能快速筛出相关的一部分书，但书架标签不准确，照样会拿错书。所以工程上会把流程做成“召回-重排-生成”：先从知识库召回 Top 20 条候选内容，再用重排模型精排到 Top 3-5 条，最后把内容喂给大模型生成答案。这样比只做向量检索多一步，但准确性提升非常明显。

工具调用是另一个关键。你要让智能体查天气、查库存、发邮件，需要把每个工具的入参、出参、使用时机描述清楚。这和写 API 文档很像，但要求更严格：工具描述含糊，模型就会乱传参。我见过一个 agent 因为把“客户ID”和“订单ID”混淆，把整个查询环节跑成了一团浆糊。所以在项目初期，我会先把工具清单列出来，测试每个函数调用的成功率和参数错误率，再开始搭 workflow。

2.3 工作流与多智能体编排：别再一个 Prompt 硬撑

很多人在搭建智能体时，喜欢把所有逻辑写进一个 prompt，让模型自己发挥。对于聊天玩具可以，但生产项目不行。一个长 prompt 里塞了检索、判断、生成、格式化、多轮追问，模型很容易在某个环节“精神分裂”，要么漏掉步骤，要么陷入循环。

我更推荐用工作流把任务拆开。Dify、Coze 这类平台提供了可视化编排，适合快速验证；agno 这类框架适合开发者用代码控制每个环节。实际项目里，我通常会把“问题理解”和“答案生成”分开：先用一个轻量模型判断问题类型，决定走检索还是走工具调用；再用更强的模型完成最终生成。这样既能保证质量，也能控制成本。

多智能体编排是最近的热词，DeepSeek 的 harness 方案也展示过多个 agent 如何组合。但我对多智能体的态度一直是：能不用就不用。因为多个 agent 通信会产生大量 token 消耗，也会引入状态同步的复杂度。如果真要用，常见模式有三种：顺序流水线，适合数据加工链路；编排者-工人模式，适合一个总控拆解子任务；协作辩论模式，适合创意类任务。前两种更稳，第三种效果好看但贵，而且容易跑飞。判断标准很简单：子任务之间能否清晰隔离。如果两个任务需要共享大量上下文，硬拆成两个 agent 就是给自己挖坑。

2.4 评估体系：没有 Eval 的智能体只算半成品

我踩过最痛的一次坑，是上线前凭感觉觉得某个 agent“还行”，结果业务同事一测，十个问题里错了四个。从那以后，我把评估放到了和开发同等重要的位置。

现在社区里常说的 evaluation 智能体，本质上是让另一个 agent 按照你定义的检查清单对输出打分。这比人肉看日志省力，但前提是评估标准要清晰。我做评估时，会把测试集分成几个维度：事实正确性、引用是否来自检索结果、步骤是否完整、语言是否礼貌、工具调用是否成功、单轮耗时和成本。每改一版 prompt 或 workflow，都跑一遍回归测试，防止“修好一个问题、打坏三个老问题”。

有意思的是，好的评估集不是一次性生成的。我在每次人工修正之后，都会把错误样本补充进测试集。三个月下来，这个 test set 已经从最初的 50 条涨到 400 多条，它才是这个项目最值钱的部分。

3. 从 0 到 1 搭一个“公司制度条例学习助手”：不是靠提示词，而是靠流程

3.1 先画边界：这个助手管哪些问题、不管哪些问题

我最近做的一个项目，是给新员工搭一个公司制度条例学习助手。最开始我以为，把公司制度文档丢进知识库，再写一个漂亮的 prompt 就行了。后来发现，真正的问题是“边界”。

我和业务方一起把助手的能力边界定成了三条：第一，回答“某制度怎么规定”这类事实性问题；第二，回答“这个流程怎么做”这类步骤问题；第三，所有回答必须带出具体条款和章节号。同时明确不做的事：不替员工判断个人是否够格享受某项福利，不回答制度里没有明文规定的内容，不处理需要跨部门确认的特殊情况。

这一步看起来不做技术，其实是技术问题。因为没有边界，模型就会自由发挥；有了边界，你才知道在 prompt 里写什么“拒绝话术”，才知道需要给哪些场景准备兜底答案。比如有人问“我这种特殊情况能不能报销”，系统会回复“制度里没有明确规定，建议咨询财务部”，而不是强行编一个“能”或“不能”。

3.2 清洗制度文档：检索质量的核心在源头

很多人的第一反应是直接做向量化，但我的经验是，清洗比向量化更重要。公司制度文档往往是从 PDF、Word 里导出来的，目录、页眉页脚、表格、加粗标题混在一起，直接切 chunk，会切出大量垃圾片段。

我先做了几件事：去掉页眉页脚和重复目录，把表格转成“键值对”似的文字描述，按制度章节重新组织文档结构。切分时，我按章节和条款作为天然边界，而不是无脑按固定长度切。每条制度条款设成一个小 chunk；如果条款太长，再用 512 字左右长度切，并保留章节号。这里有一个细节：如果条款里出现“参照第八条”这种交叉引用，必须把它和第八条的内容放进同一个上下文里，否则模型不知道“参照”的是什么。

清洗完之后的检索准确率，比直接向量化提升了不止一点。很多时候，知识库 agent 答不对，不是模型笨，而是源头太脏。

3.3 配置工作流：召回-重排-生成-引用

助手的工作流我用的是 Dify 搭的，因为业务团队后续要自己调整提示词，可视化流程比纯代码更合适。整个流程分成四步：接收问题、知识库召回、重排过滤、生成回答并附上引用。

检索参数我会先设一个基础版本：top_k 召回 20 条，chunk 大小 512，overlap 64，重排后取前 3 条。每个参数都不是拍脑袋定的。top_k 太小会漏，太大会把不相关内容送进上下文，干扰模型判断。overlap 是为了让相邻片段之间的语义不断裂，特别是制度条款里“前款”“后文”这种表达。

生成环节的 prompt，我重点强调了“严格基于检索内容回答”和“不知道就说不知道”，并要求在句末输出引用编号。这不算什么神级技巧，但配合检索阈值使用，能把幻觉压到很低。比如设置一个相关性分数阈值，低于阈值的直接走“抱歉，我没在制度中找到相关内容”的兜底分支，而不是硬答。

3.4 让智能体根据前端页面写 PRD，我踩过的另一个坑

这个项目里有个临时需求，是让 agent 根据一个前端页面的展示信息和交互来写 PRD。我第一版方案是给 agent 一张页面截图，让它“看图说话”。结果模型根本分不清按钮是否可点击、弹窗什么时候出现，生成的 PRD 全是脑补。

后来我才明白，这类任务的关键不是视觉，而是“结构化状态”。得通过浏览器自动化工具把页面里的元素、文案、跳转关系、交互事件导成 JSON，再喂给 agent。它才能真正知道“点击这个按钮会发生什么”，而不是靠猜。这让我更加确信：智能体的上限，取决于你为它准备的信息有多干净，工具定义有多准确。

4. 智能体面试在问什么，其实就是这些坑

4.1 面试官真正想听的五个主题

因为最近在帮团队面 agent 开发岗，我整理了一组高频问题，发现它们和实际踩坑高度重合。

第一个问题：什么是 Agent，和 RPA 有什么区别？RPA 是按固定脚本执行，Agent 是根据当前状态动态规划。一个稳定的 agent，要能处理“计划赶不上变化”的情况，所以它必须有观察-行动-反馈的循环。

第二个问题：ReAct 循环怎么实现？这里要能讲清楚 Thought、Action、Observation 三个部分。别只背概念，要讲一个实际例子：比如模型第一轮想到要查知识库，调用了检索工具，拿到结果后发现信息不够，再决定调用另一个工具，最后根据两轮结果做总结。

第三个问题：Function calling 的原理是什么？其实就是模型在给定工具列表里选择一个，并填好参数。考察点在于如何处理“模型选了工具但传参错误”的情况。我的经验是，工具描述里要写清楚边界和示例参数，最好在系统层做参数校验，别让错误 JSON 直接冲进业务系统。

第四个问题：多智能体之间怎么通信？很多面试者会背书“用消息队列”，但实际项目里，两个 agent 共享一个状态对象，制定好谁写、谁读，比盲目上消息队列更常见。关键是要设计清晰的任务交接协议，包括输入输出格式、超时、失败重试。

第五个问题：怎么评估一个 agent 改版是好是坏？我期待听到的是测试集、回归、指标对比，而不是“我试了试感觉不错”。这直接反映候选人的工程素养。

4.2 我回答这类问题的思路

我自己准备这类问题的时候，会按“场景-数据-流程-评估”四个角度组织答案。先讲清楚这个 agent 解决的是什么业务问题，再讲它吃了哪些数据、做过什么清洗，然后讲工作流怎么编排、在哪里设置了兜底，最后讲怎么验证效果。

这样的思路有个好处：不管面试官往哪个方向追问，你都有真实项目细节可以支撑，不会卡在概念层面。比如他说“你的重排用什么模型”，你可以直接补一句“我对比过普通向量召回和加重排后的差异，加了重排之后首答正确率提高了十几个百分点，但延迟也多了 200 毫秒，最后通过只对 Top 10 重排来控制成本”。这种“因为-所以-但我做了什么取舍”的表达，比任何标准答案都有说服力。

5. 常见问题与排查技巧实录

5.1 从“答非所问”到“一本正经胡说”：检索质量怎么排查

生产环境里最常见的现象，是智能体给了很流畅但完全不靠谱的答案。我排查的时候，第一步不是改 prompt，而是在日志里把“检索到的内容”打印出来，看模型到底看到了什么。很多时候，答案离谱是因为检索出来的 chunk 本身相关度就不高，模型为了凑答案，硬从垃圾材料里“提炼”出了垃圾结论。

遇到这种情况，我会按这个顺序查：先看文档清洗有没有漏掉错别字或重复内容；再看 chunk 切分是否破坏了语义；然后看向量检索的分数分布，如果大部分问题得分都很低，那可能是 embedding 模型或者知识库结构有问题；最后再看重排模型有没有把真正相关的排到后面。如果换了重排模型还没用，我会把 top_k 调大，让重排前有更多候选内容。

我自己的习惯是，把每个失败案例都记成一条“问答对+期望答案+实际答案+失败原因”的记录。半个月之后回头看，你会发现 80% 的错误都集中在几个固定原因里，消灭了它们，整体效果自然就上来了。

5.2 循环、超时、互相踢皮球：编排稳定性怎么保证

多智能体和工作流一旦接上真实工具，就会出现“踢皮球”。A agent 觉得该 B agent 处理，B agent 又抛回给 A，两边来回传消息，白白烧着 token。我踩过最狠的一个坑，是让两个 agent 分别负责“提取信息”和“写总结”，结果它们为了谁该输出某个字段，循环了十二分钟，账单直接爆了。

现在的处理方式很简单：所有 agent 调用都必须有最大轮数限制和单次超时。比如设“最多调用 5 次工具”，超过就停，返回当前已获取的信息并让用户决定下一步。编排者也必须有自己的决策权限：子任务失败后，是重试、换一个 agent，还是直接给用户“失败兜底”的答复，不能放任它们自由协商。

还有一个容易被忽略的点：提示词里不要让两个 agent 拥有“最终修改权”。如果两个角色的职责边界有重叠，你很难定位问题。我会确保每个 agent 只能修改自己负责的字段，其他字段一律只读。这和多线程编程里加锁的思想差不多，避免“两个人同时写一份数据”。

5.3 成本与延迟怎么压

智能体项目上线后，最怕的不是效果差，而是效果好但太贵。一个复杂问题如果让所有 agent 都跑一遍大模型，成本会非常夸张。我常用的方法是分层路由加模型降级。

具体来说，先用一个小模型判断问题类型。简单问题直接走轻量模型回答；复杂问题才调用大模型和多工具链路。这就像客服电话先让你按键分流，而不是所有来电都直接转给专家。另外，尽量缩短传给模型的上下文。很多 prompt 里塞了一大堆“角色说明”，其实每次调用时真正需要变化的只有检索结果和用户问题，我建议把静态配置从 prompt 里拆出去，只在请求时注入当前变量，能省下不少 token。

我还喜欢给工具调用加缓存。比如同一个检索问题在一个小时内被人反复问，直接走缓存结果，不需要重新 embedding 和大模型生成。实测下来，这样能把回答延迟压到原来的五分之一，而且准确率不会有损失。

5.4 智能体搭建避坑速查表

最后再分享一个我在实际项目里越来越笃定的体会：搭智能体这件事，真正难的从来不是“接入一个模型”，而是你有没有把业务边界想清楚，把数据洗干净，把评估体系建起来。投机的路，嘴上说“一键生成”，最后都得靠人一遍遍修 prompt、补数据、做验证。反而是那些老老实实从一个小场景切入、把流程跑通跑稳的项目，越做越有底气。撕掉“人生捷径”的幻想之后，我才觉得，智能体这条路终于走对了。