企业官网建设流程全解析

先说一个我最近的真实感受：前两年大家聊大模型，翻来覆去就是“问答”“生成”“总结”，能写好一段文案就觉得很厉害了。但到了今年，圈子里讨论得最多的词换成了智能体（Agent），从“你问他答”变成了“你派活他办”。

这背后其实是一次很本质的跃迁——模型不再只是负责“想”的大脑，还要长出能“干”的手和脚。我从“大脑”到“手足”这条线，拆一拆Agent到底是什么、为什么非要走到这一步，以及我们做工程的人，真正落地时该怎么想、怎么拆、怎么避坑。

1. Agent为什么火，以及它到底“新”在哪里

1.1 一个很老的概念，被大模型重新点燃

Agent（智能体）这个术语其实不是新词，早在上世纪九十年代的AI教材里就有过定义：一个能感知环境、做出决策、采取行动的系统。当时大家也设想过让计算机自己规划任务、调用外部模块、完成目标，但折腾了很多年，效果都不太理想。

问题出在“理解能力”上。传统Agent大多是靠规则引擎、符号推理、专家系统来驱动，你必须先把所有可能的情况写成if-else，或者把知识精确地形式化，一旦指令稍微模糊一点，系统就废了。所以那代Agent只适合在非常受限的封闭环境里跑，比如工业控制、特定领域的决策支持，根本走不进普通人的日常工作。

大模型出来以后，情况完全变了。模型本身有很强的常识理解、意图识别和开放语言生成能力，你不需要把每件事都预先拆成规则，只要告诉它目标，它能自己判断当前该做什么、需要哪些信息、怎么调用工具，然后一步步逼近结果。Agent的技术外壳还是老一套——规划、感知、行动、记忆——但内核从“人工写死的逻辑”换成了“大模型的泛化能力”，这是它重新火起来的根本原因。

1.2 从“问答”到“做事”：能力边界的质变

很多人会把Agent误解成“一个更聪明的聊天机器人”，这种理解会直接带偏后面所有的架构设计。聊天机器人解决的是“讲清楚一件事”，Agent解决的是“把一件事办成”。两者之间有本质区别。

我经常用一个类比：ChatGPT 像一个知识渊博但只能坐在咨询窗口里说话的顾问，你说什么他都懂，但他自己去不了仓库、改不了订单、发不了邮件。Agent则是一个带了工作台、工具包和记事本的执行者，他可以调用库存系统查数据、调API发请求、读取表格做计算，然后把结果反馈给模型继续推理。

更关键的区别在于多步决策和状态管理。问答模型每次对话是相对独立的，顶多结合一下上下文；Agent则有一个明确的任务目标，需要通过多轮“思考-行动-观察”循环逐步逼近，过程中可能走错路、需要回头、需要临时换工具。这种动态调整能力，才是“智能体”三个字里最有价值的部分。

这个表基本能说明问题：Agent和前几代产品最本质的差异是“自主规划链路”。你可以把大模型想象成一个新入职的员工，不需要每一步都告诉你怎么做，只要你把最终目标说清楚、把工具权限给它，它会自己想办法。但这也意味着，它的不可控风险比传统系统高，后面工程化部分我会专门讲怎么管理这种不可控。

2. 拆开看“大脑”和“手足”：智能体的核心模块

2.1 大脑：规划器不是大模型本身，而是“大模型+策略外壳”

Agent的“大脑”并不是大模型这一个光秃秃的模型权重，而是由三部分拼起来的：模型、系统提示词、控制策略。

模型负责理解用户意图、拆解子目标、判断当前需要哪种工具；系统提示词相当于给这个“大脑”框定了工作方式，比如“你是某业务系统的助理，必须按步骤操作”“遇到信息不足时先调用查询工具，不要猜测”；控制策略则是代码层面的循环逻辑，规定模型最多思考几轮、什么情况下要停下来找人。

规划能力目前主流的做法是ReAct风格，也就是让模型交替输出Thought（思考）、Action（行动）、Observation（观察结果）。举个例子，用户说“帮我查一下上周订单里有没有异常退款”，模型的第一轮Thought可能是“我需要先获取上周订单列表”，然后Action调用订单查询工具，拿到返回结果后进入下一轮Thought：“发现三笔退款金额异常，需要调出退款明细进一步确认”。整个过程像一个带着检查清单去工作的员工，每做一步看一眼结果，再决定下一步。

“大模型+策略外壳”这句话的意思是，纯靠模型自发的CoT（思维链）不够稳定，必须在工程上给它设定边界。比如规定“每个工具调用必须传全必需参数”“同一工具连续调用超过三次且结果相同，必须停止并上报”。模型是大脑的主体，但真正让大脑高效、稳定运转的是外面这层工程策略。

2.2 手足：工具注册、执行与结果回传

“手足”对应的就是工具调用（Function Calling）。模型本身不能直接访问外部系统，它只能“开口说”想调用哪个函数、参数是什么。真正动手去执行HTTP请求、查数据库、改文件的是外层代码。

工程上，每个工具都要注册成结构化描述，包括函数名、功能说明、参数列表、参数类型、是否必填、参数含义描述。这些描述会被拼进请求里发给模型，模型根据任务需要从中挑选合适工具并生成参数JSON。注册信息写得越清晰，模型选对工具的概率越高。这里有个很实在的经验：参数描述里一定要写“这个参数在什么场景下代表什么”，而不是只写类型。比如status字段，写成“订单状态，可选值：pending=待支付，paid=已支付，refunded=已退款”，模型就不会把 pending 误解成“未发货”。

工具执行完之后，结果会以文本形式拼回上下文，作为Observation继续给模型推理。这里需要注意：工具返回体不一定适合直接塞回大模型上下文。有些接口返回几千行的原始JSON，模型读起来既费token又容易抓错重点。比较合适的做法是在工具层先做裁剪，只把关键字段转成自然语言摘要，比如“共检索到45条异常订单，其中金额超过500元的有7条”，再喂给模型。

2.3 记忆：短期上下文和长期知识库怎么搭

记忆是决定Agent智商上限的关键模块。目前系统的记忆分三层：短期记忆、中期记忆、长期记忆。

短期记忆就是大模型上下文窗口里当前对话和工具调用轨迹。中期记忆是“需要保留但窗口快装不下”的中间过程，常见做法是做摘要压缩，把前面的思考、动作、结果总结成几句话再放回上下文。长期记忆通常落到向量数据库或外部知识库，Agent需要时通过检索把相关条目拉回来，比如“用户上一次投诉的处理偏好”“该客户公司最近三个月的业务背景”。

早期做过一个客服Agent的Demo，当时没做长期记忆，用户第二次来问同样问题，Agent完全不记得上次的处理结果，体验非常割裂。后来加了一层轻量的用户画像库，用向量检索把历史工单、历史偏好、历史结论存起来，每次任务开始前先拉取摘要，效果立刻不同。记忆这块最容易被忽视，但它和工具同等重要——没有记忆，Agent每次都是从零开始的新人。

3. 落地细节：工具调用如何做到“听话且安全”

3.1 Function Calling的请求格式与Schema设计

工具调用已经成了主流模型的标配能力，不同平台的接口细节略有区别，但核心机制一致：给模型提供一批工具描述，模型在生成回复时决定是否调用某个工具，并输出该工具的结构化参数。

以下是一个简化版的工具注册示例，以查询库存为例：

{ "type": "function", "function": { "name": "query_inventory", "description": "查询指定商品在指定仓库的实时库存数量", "parameters": { "type": "object", "properties": { "sku_id": { "type": "string", "description": "商品SKU编码，如 SKU-10086" }, "warehouse": { "type": "string", "enum": ["华北仓", "华东仓", "华南仓"], "description": "仓库名称，必须从给定枚举值中选择" } }, "required": ["sku_id", "warehouse"] } } }

Schema设计决定工具调用的成功率。我踩过的坑主要有三个：第一，参数名不要太短，id、type这种词模型经常分不清指哪个实体的id；第二，取值范围如果有限就用enum明确写出来，不要让模型自由发挥；第三，description里要写清楚单位、时区、边界条件，比如“库存数量，单位：件，查询的是当前实时值，非可售库存”。

3.2 返回体的校验与纠错

模型输出工具调用时并不保证参数一定合法，它可能生成一个不在枚举范围内的仓库名，也可能漏掉必填字段。工程上必须有严格的校验层，不能直接拿着模型生成的JSON去发起请求。

通常做法是：先把模型输出的JSON parse 成结构化对象，再做类型和枚举校验，校验失败后把错误信息回传给模型，让它自行修正。比如“参数 warehouse 非法，可选值为华北仓/华东仓/华南仓，请重新调用”，模型一般就会自我纠错。但要加一道保险：连续重试两次以上仍然校验失败，就停止循环并转人工，避免陷入“校验-报错-重试”的死循环。

还有一种常见问题是“幻觉参数”——工具本身没有这个字段，模型擅自加了。校验层要开启严格模式，多出来的未知字段直接拒绝，而不是忽略。忽略未知字段会让模型误以为它调用的方式是对的，下一次还会继续错。

3.3 危险工具的人机协同守门

工具不是越多越好，尤其是涉及资金操作、删除类操作、对外发送消息的工具，必须设计“人机协同守门”。最简单的做法是把工具分为只读型和写入型两类：只读工具让Agent自主调用，写入型工具一律进入“待审批”状态。

实际跑过一个发货异常处理Agent，它的退款工具就是需要审批的。Agent把“订单号、退款金额、退款原因、建议方案”全部生成好，推到审核队列里，由人工点确认后才真正执行。这个设计既保留了Agent的高效执行能力，又把最终风险控制在人的手里。

另一个安全细节是审计日志。每一个工具调用的入参、出参、模型思考过程、执行时间都要留痕。万一出了事故，要能完整复盘当时模型看到了什么、基于什么做了决策。我在实际项目中把每次运行的trace都落成结构化的JSON日志，回滚定位问题时非常方便。

4. 实操复盘：把一个问答模型改造成Agent的路径

4.1 第一步：把任务拆解成“可工具化”的原子能力

并不是所有任务都适合Agent化。改造之前先做一轮任务拆解：把目标场景里所有需要的能力列出来，凡是涉及外部数据、外部动作的，都要变成可复用的原子工具；凡是可以靠模型内部知识直接回答的，就不需要上工具。

举一个改造客服系统的例子。起初只是一个纯问答机器人，用户问“发货到哪了”“怎么退货”“运费多少钱”之类的问题，机器人只能基于知识库给通用说明。改造时列出的原子能力包括：订单详情查询、物流轨迹查询、售后规则计算、运费试算、退货单创建。每个能力对应一个可以被工具层调用的API，而不是一段话术。

拆解的原则是“工具粒度要刚好合适”。粒度太粗，一个工具里面嵌套了大量业务逻辑，模型只能“一次调用全做”，灵活性差；粒度太细，比如把运费和保价拆成两个工具，模型可能因为调用顺序混乱而算错。我当时调了几轮才找到合适的边界：按“用户能在一次操作中感知到的完整动作”来切，比如“查询整笔订单的所有商品明细”是一个工具，而不是“查询订单第一条商品”“查询订单第二条商品”。

4.2 第二步：定义Agent主循环，用代码明确状态流转

下面是主循环的简化伪代码，逻辑顺序可以套用到很多场景里：

async def run_agent(task: str, tools: dict, max_rounds: int = 10): context = build_initial_context(task) for round_idx in range(max_rounds): response = await llm.chat(messages=context, tools=list(tools.values())) if response.tool_call: # 校验工具参数 validation_result = validate_call(response.tool_call, tools) if not validation_result.ok: # 把校验失败原因回传，让模型自行修正 context.append("system", f"工具调用参数不合法：{validation_result.error}") continue # 执行工具，并把结果摘要写回上下文 result = await execute_tool(response.tool_call, tools) context.append("observation", summarize_result(result)) else: # 模型认为任务已经完成，输出最终答复 return response.content # 超出最大轮次仍未结束，转人工接管 return escalate_to_human(context)

这段代码里有几个关键设计点值得展开。

第一，max_rounds上限。没有轮次上限的Agent很容易在复杂任务里无限循环，每循环一轮就多烧一轮的token，预算控制不住。实际系统中我在10轮之后会先转人工，而不是强行结束，因为有些任务确实需要20轮才能完成，但超过10轮还没完成通常意味着中间出了问题。

第二，校验失败信息要放回上下文而不是直接丢弃。这是让模型“自我纠错”的基础，很多Demo失败就失败在工具参数校验不过时直接返回error: param invalid，模型根本不知道是哪个参数、错在哪、应该填什么。把错误描述写得跟工具描述一样详细，模型下次调用的成功率会高很多。

第三，工具结果要summary。直接把几KB的工具结果塞回上下文，不仅占用窗口，还会把模型的注意力带偏。

4.3 第三步：用评测集验证“会做”而不是“会说”

问答模型的评测看回答相关性和流畅度，Agent的评测必须看“任务完成率”：给定一个带有明确目标的任务，判断Agent最终是否达到了目标状态。评测集的构建要覆盖成功路径、边界路径和失败恢复路径，例如“查询订单并计算退款金额”“查询一个不存在的订单号并给出合理反馈”“工具连续报错两次后及时转人工”。

我当时构建了一个50条任务的评测集，每一条都有明确的通过标准，不只看最终文字“长得像不像正确答案”，还看是否按预期调用了工具、路径是否合理、有没有多余的无效动作。跑评测的过程让我发现一个高频问题：模型在没有把握时会编造一个相对合理的数字来回答，这放在问答场景其实就是常见的“模型幻觉”，但在Agent场景里就是事故。解决办法是给系统提示词里加一条硬性约束：“如果工具返回结果为空或异常，如实说明，禁止推测数据”。

评测通过后，再放到真实流量里灰度，一开始只放5%的比例，人工抽检没问题了再逐步放开。Agent这类系统没办法做到“测过就稳定”，必须保持灰度意识。

5. 工程化路上的坑：可靠性与调试经验

5.1 循环不退出与token爆炸

Agent最常见的故障就是“在同一地方反复打转”。模型可能因为工具返回结果的表达方式问题，把同一个查询动作重复执行，每次拿到一样的结果，依然继续发起同样的调用。这时候光靠轮次上限能兜底，但体验很差，因为问题没有解决就转人工了。

我在工程上加了三层防护：第一层是“重复调用检测”，统计同一参数的同一工具在连续10轮内出现次数，超过3次直接中断并提示模型换个方向；第二层是“结果不变检测”，如果新结果和上一次的结果完全相同，把“结果不变，请勿重复调用同一工具”作为系统消息写回上下文；第三层是总轮次硬上限，三层都挡不住的时候，再转人工。

另一个容易被忽略的问题是工具返回体过大导致的token爆炸。有一次接了一个BI查询工具，直接返回了500行明细数据，一轮下来的token消耗相当于平时十轮。后来我们给工具层加了一个自动分页和摘要机制：超过30行明细不直接给模型，而是先给统计信息“共500行，其中金额最大的是……”，模型需要看明细时再按页拉取。

5.2 上下文污染：工具结果塞满窗口以后怎么办

多轮Agent运行到后面，上下文里堆积了大量Observation文本，真正有用的信息会被淹没。更麻烦的是，旧的错误尝试、失败的调用记录也会一直留在上下文里，对后续推理造成干扰。

我采用的双层清理策略：一是“滑动窗口+摘要”，始终保留最初的系统提示词、最近两轮完整思考和行动轨迹，中间过程全部压缩成一段一二百字的摘要；二是“失败记忆隔离”，失败的调用记录不进正式摘要，而是单独存到日志里，只在模型需要“看看之前试过什么”时按需检索。这样既保留了必要的记忆，又不会让噪声长期霸占宝贵的上下文空间。

5.3 从trace里看问题：给Agent装个“黑匣子”

Agent调试比传统接口调试难得多，因为同一个输入在不同时间跑出来的路径可能完全不同。曾经有一个投诉处理任务，测试时一切正常，上线后开始乱报错，但复现不出同样的问题。后来发现是线上某个下游API偶尔会返回一个空字段，导致工具结果摘要格式错乱，模型误判为“没有数据”。

从那以后我养成了一个习惯：每次运行都完整保存一份trace，包含完整输入、每轮模型原始输出、工具调用JSON、工具返回原文、最终答案，并用一个唯一ID关联。出问题时不靠“猜”，而是直接回放trace，看到底是哪一步开始走偏的。这套trace体系花不了多少开发量，但对Agent质量管理的价值非常大。

除了trace，还要维护“回归测试集”。每轮迭代后跑一遍之前积累的所有历史case，确保修了新bug没有引入老问题。Agent系统跟传统软件不一样，一次模型版本升级就可能让整个行为风格改变，没有回归测试在背后兜着，上线就是开盲盒。

6. 人机协作范式正在被改写：数据、流程和团队

6.1 人在回路不是摆设，而是最高优先级的路由器

Agent越强大，人机边界越需要重新划分。我现在的设计原则是：确定性环节全部交给Agent，不确定性环节先找人确认，风险敞口必须留人工闸口。

所谓“确定性环节”，指的是输入明确、工具能执行、结果可验证的动作，比如查物流、算运费、生成周报草稿。所谓“不确定性环节”，包括目标本身模糊（“帮我把这个客户搞满意”）、多个目标之间有冲突（“既要清库存又要保利润”）、以及模型明显犹豫的情况。人在这里扮演的是“路由器”而不是“操作员”——不负责每个步骤的细节，只负责在关键岔路口做方向性决策。

这和以前“人+计算机”的协作方式有明显的区别。过去是人定义一切流程，计算机机械执行；现在是Agent承担了大部分中间过程，人只输入目标和校验结局。这带来的好处是效率提升，代价是对人的“验收能力”要求变高了——你不需要知道每个步骤怎么做，但必须能判断结果对不对。

6.2 组织里的“技能分配”在变化

推过几个Agent项目之后，我注意到团队的技能分配也在跟着变化。以前最缺的是写业务代码的人，现在最缺的是能把业务过程拆成“工具集+策略规则”的人。怎么把“判断退货是否超期”这种模糊经验，变成Agent可执行的工具逻辑和回复策略，这已经成了新的核心能力。

具体到岗位层面，一个Agent项目团队里至少要有三类角色：一类负责梳理领域知识和原子能力边界，决定哪些动作需要工具化；一类负责模型层和工具层的接口工程，包括Prompt、Schema、校验、trace等；还有一类负责评测和灰度验证，持续把线上问题转化为回归case。三个人围着同一套系统转，比一个全栈工程师单打独斗要靠谱得多。

我还观察到一个趋势：Agent会让很多“执行型”的岗位从“做”变成“验收”。比如客服专员可能不再逐单回复，而是处理Agent跑不完的异常单；数据分析师可能不再写SQL拉数，而是定义“这个指标异常时需要Agent自动排查到什么程度”。这个转变对个人能力结构的影响，会比我们预想的来得更快，也更深入。

6.3 别急着上多Agent，先把单Agent打磨好

每次看到有人一上来就设计三五个Agent互相协作，我都想劝一句：团队协作的前提是每个成员都能独立完成任务。单Agent还没跑稳之前上多Agent，只是把单点的不可控问题乘以N，最后会收到一个巨大的不可调试黑盒。

我当时就是先花了大量精力把单个客服Agent的规划、工具调用、错误恢复打磨到可接受水平，才开始让它和另一个数据分析Agent协作。这时候协作是简单的“你把中间结果传给我”，而不是一开始就做复杂的互相辩论、动态分工。

如果你刚开始接触Agent，我的建议是：找一条具体的、窄的业务线，比如“异常订单处理”“库存预警排查”，先把一个Agent从0到1跑通，再谈规模的扩展。与其搭一个看起来很完整但跑不稳定的系统，不如先把某个单点做到让人真正愿意用。

7. 给想上手的团队一点私人建议

最后再分享几个实操心得，都是被真实项目打磨过之后留下的经验。

第一，工具返回结果要“说人话”。模型虽然能读JSON，但把结果转成一段简洁的自然语言摘要，能显著减少模型的误判率。比如工具返回{"total": 3, "items": [...]}，可以封装成“共找到3笔疑似异常退款，最大一笔金额为899元，详情如下……”。模型对这类文本理解更稳定。

第二，系统提示词里一定要写“面对不确定信息时的处置方式”。我见过很多Agent在不确定时选择硬猜或者乱表态，根源就是提示词里没写清楚处理策略。加上一条“当信息不足时，优先调用工具补充信息；工具也无法获取时，明确告知用户并建议人工处理”，大多数乱猜问题都会消失。

第三，灰度发布不是可选项而是必选项。Agent行为的不确定性决定了它不可能一次测好，小流量、高频监控、快速回滚这套机制一定要提前做好。

我自己做Agent项目最大的体会是：不要神化它，也不要低估它。它像是一个各方面能力都还不错的“新人”，需要明确的目标、趁手的工具、清晰的边界和靠谱的管理机制。把这套管理机制做好了，Agent确实能接走大量重复性的执行工作，把人的精力解放出来去处理真正需要判断力的事情。