企业官网建设流程全解析

去年夏天，团队内部上线了一个问答机器人，第一周大家热情高涨，第二周就几乎没人再点开它。原因听起来有点讽刺：它太"会聊天"了，聊得再漂亮，也不会真的把要做的事办掉。同事问它"上季度的需求文档更新了哪些内容"，它回复一大段得体的话，可没人知道这段话靠不靠谱，更没人指望它去文档库里把新旧版本差异真正拉出来。

这个场景几乎每天都在各种团队里重演。大语言模型的强项是理解和生成文本，而"做事"意味着理解之后还要决策、决策之后还要执行、执行之后还要检验。中间缺的不只是一个API，而是一整套把模型能力延伸到真实系统的机制。这套机制，就是现在被频繁提到的AI Agent。

这篇文章不打算讲概念层面的花活。我会从"会聊天"和"能做事"的本质差异讲起，拆解Agent内部真正干活的那几套机制，再用一个我做过的合同处理Agent作为实例，把工具设计、编排逻辑、实测翻车记录都摊开。最后聊一聊哪些场景适合Agent、哪些场景是在硬凑，以及一套务实的落地路线。不管你是在评估技术方案，还是准备亲手搭第一个Agent，这篇都应该能给你一些可以"抄作业"的东西。

1. 从对话窗口到执行入口：Agent把"理解"变成了"行动"

1.1 聊天机器人为什么"不会做事"

市面上大多数聊天机器人，本质是一个"文本续写器"。你输入一句话，模型根据训练阶段学到的统计规律，把最可能接下去的内容生成出来。它能写诗、能总结、能翻译，是因为这些任务恰好属于"语言空间里的变换"。但"做事"要跨越的不只是语言空间，还有现实空间。

想一想用户说"帮我把本周销售数据整理成周报"这件事。聊天机器人能做的，是给你一段周报模板，或者一段零零散散的建议。它拿不到本周真实订单，不会去数据库执行查询，更不会把图表嵌进文档。你可以把它想成一个非常博学的顾问，坐在那里口若悬河，但手和脚都被绑住了。顾问的建议再有价值，真要落地执行，还是得靠别人跑腿。

我并不是说聊天式交互没有价值。恰恰相反，理解能力是Agent的地基。但只有当模型不再满足于"说出答案"，而是能"拿到证据、执行动作、交付结果"时，它的价值才从"信息提供"升级为"事务处理"。这一步的跨越，靠的是把模型放进一个有工具、有反馈、有循环的系统里，而这个系统，就是Agent。

1.2 一个最小可工作的Agent循环

很多人第一次接触Agent时，容易把它想象成一个"更聪明的模型"。其实Agent不是模型本身，而是模型加外围机制组成的一个闭环。最简形式可以概括为四个英文单词：Think、Act、Observe、Repeat。

模型先接收任务，想一下该怎么做；然后决定调用哪个工具、传什么参数；工具执行后把结果返回给模型；模型看到结果，判断任务是否完成，没完成就继续下一步。这个循环必须显式地写出来，不能指望模型一步到位。

def agent_loop(task: str, tools: dict, max_steps: int = 6) -> str: messages = [ {"role": "system", "content": "你是一个可以使用工具的智能助手，每轮先思考再行动。"}, {"role": "user", "content": task}, ] for step in range(max_steps): response = llm.chat(messages, tools=TOOL_SCHEMA) # 模型认为可以直接给出最终答案 if response.is_final_answer(): return response.content # 模型决定调用某个工具 call = response.tool_call observation = tools[call.name](**call.arguments) # 把工具结果放回上下文，让模型继续推理 messages.append({"role": "tool", "name": call.name, "content": str(observation)}) messages.append({"role": "assistant", "content": "工具结果已返回，请继续判断任务是否完成。"}) return "达到最大步骤上限，请调整任务或检查工具是否可用"

这段伪代码虽然短，但它点出了Agent区别于聊天机器人的核心逻辑：模型不直接产出一个答案，而是产出一连串的动作决策。每个动作带来的新信息，都会重新进入模型的上下文，影响接下来的判断。这就是"从输出文本到输出行动"的转变。

1.3 "革命"而不是"升级"：三个关键转变

把上面这个循环放到实际业务里，你会发现它带来的不是"聊天体验变好了"，而是整个软件交互范式变了。我总结了三个关键转变。

第一，从一次生成到多轮闭环。传统聊天是一次问答，用户问完就结束。Agent是带着状态跑的，任务没完成就是没完成，闭环直到交付结果或触发终止条件。它更像一个执行流程，不像一段对话。

第二，从语言空间到动作空间。模型不再只输出自然语言，它可以输出结构化的工具调用指令，比如{"name": "query_database", "args": {"sql": "..."}}。真正做查询的是后端工具，模型负责决策，工具负责执行。两者解耦后，模型能力边界被大幅扩展。

第三，从静态回答到环境交互。聊天机器人回答问题时不依赖外部世界的实时状态，Agent每一步都在接触真实数据——数据库里多了一条记录、文件被修改了、接口返回了新的状态码。它感知的是"此刻的环境"，而非训练数据里固化的世界。

理解了这三个转变，再看市面上各种Agent演示，你就能分辨哪些是套壳聊天、哪些是真正在执行。

2. 拆开引擎看活塞：Agent能干活依赖的四套机制

2.1 工具调用：给模型装上"手"

Agent能"做事"最直接的原因，是它可以调用工具。但工具调用不是简单地给模型拼一个函数列表，它依赖一套结构化的接口协议。模型需要知道：有哪些工具、每个工具是干什么的、参数应该怎么填。

我在项目中最常用的做法，是把工具描述写成JSON Schema形式，包含name、description、parameters三部分。其中description写得越具体，模型触发工具的准确率越高。比如：

{ "name": "retrieve_contract_chunk", "description": "在合同向量库中检索与查询最相关的段落。适用于用户询问付款条款、违约责任、保密协议等具体条款内容时。", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "用户关心的核心问题"}, "top_k": {"type": "integer", "description": "返回段落数量，默认3"} }, "required": ["query"] } }

这段描述看起来简单，实际影响非常大。有一次我把description写成"检索合同段落"，模型经常在用户提出"这份合同要不要续签"这类判断性问题时不调用检索工具，直接凭上下文乱答。改成"当用户询问合同中的具体条款内容时"之后，触发率明显提升。工具描述的本质是教模型"什么时候该用这只手"。

还有一个工程细节：工具的返回结果不能太长。向量检索返回了十段文本，每段几百字，一口气塞回上下文会把关键信息淹没。我会在工具层先做截断和重排，只保留与查询最相关的三到五段，再返回给模型。记住，Agent的推理质量很大程度取决于"喂给它的观察结果"干净不干净。

2.2 任务规划：把大目标拆成小步骤

有了工具，模型还得知道"按什么顺序用、用到什么程度停"。这就是规划机制。

在复杂任务里，我倾向于让模型先输出一个执行计划，把任务拆成若干子步骤，再逐步执行。以合同的"结构化抽取"为例，完整任务拆成四步：

1. 解析文档，获取全文文本。
2. 将文本切片并向量化，建立索引。
3. 按字段清单逐项抽取关键信息。
4. 校验字段完整性，缺失的重新抽取或标记人工确认。

这种"先计划、后执行"的方式，比让模型一步到位直接输出结果要稳得多。背后逻辑是：每一步都缩小了搜索空间，模型在每个子步骤上只做一件相对简单的事，出错概率自然下降。

规划并不总是需要复杂的调度算法。我见过很多团队上来就套任务分解框架，结果简单任务也被拆得七零八落，反而拉长了响应时间。我的建议是：任务步骤少于两步时，让模型直接决策；只有任务天然具备多阶段特征时，才引入显式规划流程。规划是为了降低复杂度，不是为了展示技术。

2.3 记忆体系：记住对话、任务和长期偏好

Agent的第二只手是记忆。聊天机器人也有多轮上下文，但那只是短期记忆；Agent真正有用的记忆体系至少分三层。

短期记忆就是当前任务的上下文窗口，包含用户原始指令、每轮工具调用和返回结果。它决定了当前任务的连贯性。中期记忆是任务状态，比如"文档已解析""已抽取字段3/5"，用于在中断后恢复执行。长期记忆则依赖外部存储，我把结构化的用户偏好、历史决策记录、常见问题解答存放在数据库里，需要时通过检索拉回上下文。

举一个实际例子。合同处理Agent在第一次被问到"我们通常接受的付款账期是多久"时，如果库里已经存了团队的历史偏好记录，它可以直接检索到"最多接受30天账期，老客户可到45天"这条规则，再结合当前合同的条款给出判断建议。没有长期记忆的Agent，每次遇到类似问题都像失忆一样重新推理，不稳定且低效。

设计记忆体系时，我会提醒自己：记忆的意义是让Agent避免重复劳动，同时保持决策一致性。如果你发现Agent在同一个问题上两次回答不一致，大概率是记忆层没接好。

2.4 自我反思：错了不要紧，要紧的是会改

Agent和静态机器人还有一点不同：它能看见自己动作的结果，并据此修正策略。这个能力在行业里常被称为反思或自我修正。

工具调用不是每次都成功的。接口可能超时，SQL可能有语法错误，解析器可能遇到不支持的格式。如果模型只会按原计划继续走，一个错误可能滚成更大的错误。正确的做法是把错误信息原样返回给模型，让它重新决策。

我设定的标准流程是：工具层捕获异常，返回结构化的错误信息，例如{"error": "file_not_found", "detail": "指定路径不存在"}，模型看到后可以换路径、换工具、或者向用户请求补充信息。同时给整个循环设定最大步骤数，防止它在一个错误里反复打转。

反思机制最容易被忽略的部分是"记录失败模式"。我会在日志里把每次工具调用失败的原因归类，比如参数格式错误、权限不足、文件损坏。跑一段时间后，从统计里能看出哪些工具描述需要优化、哪些场景需要加预处理。这比事后人肉复盘高效得多。

3. 落地实录：从零构建一个合同管理Agent

3.1 场景选择：为什么先做"文档型Agent"

讲完原理，我拿一个实际做过的小项目来拆解。这个项目的目标是做一个合同管理Agent，用户上传合同文件后，能自动抽取关键条款，还能用自然语言提问："这份合同的付款期限是多久？""违约金比例是多少？"。

为什么选这个场景？因为它是典型的"多步骤、要真实数据、结果可验证"的任务。合同是静态文档，不需要跨系统权限，工具集可以控制在四五个以内，风险边界清晰。对新团队来说，这是练手Agent的最佳复杂度——不会简单到没有意义，也不会复杂到失控。

选这个场景还有一个私心：它能把Agent的核心机制全部用上。工具调用负责解析和检索，任务规划负责字段抽取流程，记忆体系存储历史合同的处理结果，反思机制处理解析失败和字段缺失。一个项目练完，整套经验可以迁移到报表生成、工单处理等场景。

3.2 工具集与数据流设计

我设计的工具集如下：

数据流是这样的：用户上传合同文件，Agent调用parse_document解析出文本；文本交给chunk_and_index切成短段并向量化；用户提问题时，retrieve从向量库里找出相关内容；需要抽取结构化字段时，extract_fields逐项抽取；最后verify_result检查有没有漏抽，有漏就决定是重新抽取还是标记人工复核。

这个数据流的设计原则是：每个工具只做一件边界清晰的事，Agent负责编排。一旦某个环节出问题，你能精准定位是解析的锅、检索的锅还是模型决策的锅。

3.3 编排逻辑与关键代码思路

核心编排逻辑用伪代码呈现如下：

SYSTEM_PROMPT = ( "你是一个合同管理助手。用户可能上传合同文件，也可能直接提问。" "遇到问题时应先检索相关合同内容，再基于检索结果回答。" "抽取字段时必须调用extract_fields，不要凭记忆填写。" ) TOOL_SCHEMA = [ { "name": "parse_document", "description": "解析本地PDF或Word合同文件，返回纯文本", "parameters": { "type": "object", "properties": {"path": {"type": "string"}}, "required": ["path"], }, }, { "name": "retrieve", "description": "在合同向量库中检索与查询最相关的段落", "parameters": { "type": "object", "properties": { "query": {"type": "string"}, "top_k": {"type": "integer", "default": 3}, }, "required": ["query"], }, }, ]

代码本身不复杂，但有几个地方我在第一次实现时踩了坑。

第一个坑是：为了省事，我把extract_fields设计成"一次传入所有字段"，结果模型经常漏掉后面的字段。原因是待抽取字段一多，上下文里的注意力被前面的字段稀释了。后来改成一次只抽一个字段，循环调用，准确率立刻上来。牺牲了一些调用次数，换来更稳定的结果，这笔账是划算的。

第二个坑是：工具返回的结果我没有加结构约束，直接把数据库查询结果的原始字典塞回上下文。字典里有很多与用户问题无关的字段，把模型的注意力带偏了。后来每个工具返回前都做一次"裁剪"，只保留对后续决策有意义的字段。

3.4 实测表现与两个翻车修复记录

实测阶段我用三十份脱敏合同做了测试，其中涵盖扫描件、电子签章件和扫描加手写批注的混合件。字段抽取的完整率从第一版的百分之七十几，经过两轮修复后稳定在百分之九十五以上；普通提问的响应时间在三到五秒之间，复合检索加抽取的流程在十秒左右。

第一个翻车记录是扫描件问题。第一版parse_document直接调用PDF文本抽取接口，遇到扫描版合同时返回的是乱码。用户问"违约金比例"，Agent检索到乱码段落，给出的答案牛头不对马嘴。修复方案是在解析失败时自动切换到OCR流程，并把"文件为扫描件"这个状态写进上下文，后续抽取和检索都会自动按图像识别结果处理。

第二个翻车记录是字段校验逻辑。早期verify_result只看"字段是否存在于返回结果里"，后来发现有些字段模型填了一个空字符串，校验直接通过了。改成"校验非空且符合基础格式"之后，比如金额字段必须匹配数字模式、日期字段必须匹配日期模式，漏抽率和误抽率同时下降。这个教训让我明白：Agent的校验机制要和工具层的真实约束对齐，不能只做存在性检查。

4. 项目上线前必须想清楚的四件事

4.1 上下文窗口不是无限的记忆

Agent每次调用工具后都会把结果塞回上下文，几轮下来，上下文可能被工具返回撑爆。我在一次测试中发现，任务是"从十份合同里找出付款条件最宽松的一份"，每检索一份合同，检索结果加模型中间推理就占用了两千多token，五轮之后上下文接近临界值，模型开始遗忘最初的任务约束。

解决思路有三种，可以组合使用。一是中间摘要，每两到三轮让模型把已获得的关键信息压缩成一段短文，替换掉原始的工具结果。二是结果截断，工具层控制返回数据的长度，只保留与当前子问题直接相关的部分。三是把长期记忆抽离到外部存储，需要时再检索，而不是全部堆在上下文里。

上下文管理的核心原则是：让模型始终看到全局目标，同时只暴露当前步骤需要的细节。全局目标放在系统提示词里固定不动，细节按需加载，这样即使执行到第十步，模型的决策质量也不会明显下降。

4.2 工具返回的数据比模型输出更会坑人

大多数人把Agent的稳定性归因于模型聪明不聪明，但我在项目里发现，更多事故发生在工具返回的数据质量上。数据库字段里的值可能是"2024年3月21日"，也可能是"3/21/2024"，还有可能是"按合同约定执行"。这些格式不一致的数据进入模型上下文后，模型会做出各种奇奇怪怪的推断。

我的对策是在工具层加一个标准的清洗与校验流程。日期统一格式，金额统一保留两位小数，"无""暂无""按约定"这类模糊值统一标记为unknown，并在返回给模型之前完成类型校验。如果数据源本身存在无法自动处理的脏值，工具可以返回一个明确的状态，比如{"field": "payment_due", "value": null, "reason": "unrecognized_format"}，模型看到后就知道不能瞎猜，必须触发人工复核分支。

这种做法相当于在模型和现实世界之间加了一道防火墙。模型可以不够聪明，但工具返回的数据必须稳定可预期。大部分被吹得天花乱坠的Agent Demo，一到真实数据环境就露馅，根子就在这一层没做好。

4.3 每一轮调用都在烧钱：成本与性能平衡

Agent的成本结构比普通聊天机器人要贵得多。一次复杂任务可能涉及五到八次模型调用，每次调用都要携带累积的上下文，token消耗呈递增趋势。我算过一笔账，一个日常合同问答任务大约消耗两万到三万token，换算成成本是聊天的几倍到十几倍。

控制成本有几个实测有效的手段。第一，给每个Agent设置最大调用次数，限制死循环。第二，对相同或高度相似的工具调用结果做缓存，比如相同的合同片段、相同的检索结果，不需要每次都重新生成token。第三，在入口处用一个轻量分类模型判断任务类型，简单问题直接用小模型回答，复杂问题才路由到完整Agent链路。第四，长文档不要每次全量塞给模型，先检索后抽取，只在必要时把具体段落送入上下文。

成本控制不是把参数调小那么简单，而是要在架构层面把"每次都要靠大模型硬想"变成"能查的查、能缓存的缓存、能路由的路由"。这样做了以后，我的实际支出下降约百分之四十，回答质量几乎没有变化。

4.4 安全边界：Agent能调工具，会不会闯祸

Agent变得越能干，风险边界就越需要画清楚。一个会调数据库接口的Agent，理论上可以把表删了；一个能发邮件的Agent，理论上可以给全公司群发错误内容。我在项目中坚持几条原则。

最小权限原则是底线。Agent的工具权限应该只覆盖当前任务需要的最小范围，比如合同管理Agent只读文档目录，不碰生产环境数据库；需要写操作的场景，写入工具必须做参数白名单校验。敏感操作二次确认，删除、覆盖、发送、审批这类不可逆操作，默认要经过人工确认节点，不直接自动执行。全程审计也不可少，每一次工具调用的时间、输入、输出都记录日志，出问题时能回溯。

有一次测试里，Agent在检索未能满足需求时，居然编造了一个不存在的工具名，想让系统调用它。这个细节提醒我：护栏不是提防模型"变坏"，而是提防它"犯傻"。系统的鲁棒性必须建立在工具层和安全层的确定性约束之上，而不是建立在对模型自律的信任上。

5. Agent不是万能的：选场景比调模型更重要

5.1 高ROI场景的三个特征

做了几个Agent项目后，我归纳出适合Agent落地的场景都具备三个特征：多步骤、要真实数据、结果可验证。

多步骤意味着Agent的规划与工具调用能力有用武之地，任务越单点，Agent相对传统脚本的优势越小。要真实数据意味着模型不能只靠训练记忆作答，必须通过工具获取实时信息，这正好是Agent的长处。结果可验证意味着你能为Agent的成功定义一个客观标准，比如"关键字段抽取完整率""工单自动分派准确率"，没有客观标准的任务很难调优。

符合这三个特征的典型场景包括：客服工单自动分诊与回复辅助、报表数据拉取与解读、合同文档的条款抽取与问答、代码仓库的变更分析。这些场景的共同点是边界清晰、数据可得、效果可度量，拿来做第一个Agent项目最合适。

5.2 我踩过的"伪需求"与不适合Agent的领域

我也踩过用Agent硬凑需求的坑。有段时间团队想做"自动写周报Agent"，老板希望成员每天提交工作记录后，系统自动生成周报。结果上线后发现，周报里引用的数据除非严格结构化，否则Agent汇总时会脑补出很多不存在的进展；负责人不放心，每天还得人工核对一遍，ROI直接为负。这就是典型的"结果不可验证"问题——周报写得好不好没有客观标准，人的信任成本降不下来。

不适合Agent的领域也分几类。纯创意类内容产出，比如广告文案、品牌故事，需要极强的审美与主观判断，人类参与价值很高，Agent只能做素材铺垫。医疗诊断、司法建议、金融投资这类高风险决策，哪怕Agent只是辅助，责任归属问题也绕不开，建议以"信息检索+人工决策"的方式切入，别贸然做全自动。还有一类是对接系统极其封闭的场景，Agent要跑的业务逻辑全部藏在一个没有API的老旧系统里，工具层做不出来，Agent再强也等于断手断脚。

选场景时我会问自己一个问题：如果这个任务换成一段普通代码自动化，能不能做到八成效果？如果能，那未必需要Agent；如果代码只能按固定路径跑，遇到变化就失灵，而规则常常变化——这才是Agent真正该进场的地方。

5.3 务实的落地路线：先单点、再编排、后闭环

最后聊一套我在多个项目里反复验证过的落地路线。第一步是单点突破，只接一个工具、解决一个明确痛点。比如先做一个"合同解析工具"，让用户上传文件就能拿到结构化摘要，哪怕没有完整的Agent循环，先跑起来积累数据。第二步是多工具编排，把解析、检索、抽取、校验串起来，形成最简Agent闭环。这时候你会真正感受到"工具返回值如何影响模型决策"这个核心命题。第三步是嵌入业务流程，接入企业内部的审批、消息通知、权限体系，让Agent从"被用户调用"变成"出现在业务流程的关键节点上"。

这套路线的优点是把风险摊薄了。每个阶段都有可验证的交付物，不会出现憋了三个月最后发现方向错了的情况。我见过不少团队一上来就搞"超级Agent"，想同时打通十几个系统，结果半年过去还在和权限、数据格式搏斗。与其这样，不如先让一个Agent在一个小场景里稳定跑起来，把工程细节打磨成熟后，再横向复制。

从"会聊天"到"能做事"，我越来越觉得不是模型参数发生了什么突变，而是我们把模型放进了一个包含工具、反馈、控制机制的真实系统里。模型依然是那个会续写文本的模型，但它的决策开始作用于现实世界，并且能观察到作用的结果。这一步看起来只是工程架构的变化，实际带来的交互范式和价值空间，比很多人想象的都要大。如果你也想做，建议从一个小但真实的业务场景开始，认真为它铺好一条通往真实世界的路。