企业官网建设流程全解析

最近一段时间，各大技术社区里“AI Agent”几乎成了流量密码，任何人都能搭出一个听起来很酷的演示：问它一句话，它能自己打开网页、查资料、算数据，最后给你一份整理好的答案。但是等我自己动手把这个概念搬进真实业务之后，才发现“演示”和“好用”之间隔着一条巨大的河。这篇文章就是我把 AI Agent 从概念到落地走完一遍之后提炼出来的“驾驭指南”，主要聊四件事：什么才算 Agent、最小可用结构怎么搭、怎么让它不乱跑、以及上了线之后如何控制成本和排查故障。如果你是一个正在尝试把 Agent 接进产品、又要对效果负责的开发者，或者刚接触这个方向想少走弯路的工程师，应该会很有用。

1. AI Agent 究竟是什么：先把“能聊天”和“能干活”分开

1.1 我见过最多的误解：Agent 等于 Chatbot

过去两年我参与过不少技术评审会，几乎每一次都会遇到有人把 Agent 和 Chatbot 混为一谈。很多人觉得，只要接了大模型接口，能连续对话、能理解上下文，就已经是 Agent 了。这个误解的代价很高：团队按 Chatbot 的架构设计了产品，等真正要让它处理业务时才发现，模型只会“说”，不会“做”，于是又回头补工具调用、任务编排、状态管理，等于把系统重做一遍。

Chatbot 的核心是“生成回复”，它的终点是文字。Agent 的核心是“完成任务”，它的终点是行动和结果。举个例子：客户在售后页面问“我的订单到哪了”，Chatbot 会生成一段话：“请您提供订单号，我来帮您查询。”而 Agent 应该能做到：自己去订单系统查到状态，发现物流已经两天没更新后主动触发人工介入，并把处理进度同步给客户。两者的差别不在“说话水平”，而在“有没有对外部世界产生作用”。

判断一个系统是不是 Agent，我习惯问三个问题：它有没有明确的任务目标？它能不能把目标拆解成若干步骤？它有没有调用外部工具的通道？三个都满足，才算真正入了门。

1.2 Agent 的三大特征：目标、规划、行动

先看第一个特征：目标。Agent 不是被动地等待用户一句一句指挥，而是接收一个相对模糊的需求后，自己定义一个可执行的目标。比如用户说“帮我准备下周的项目周报”，它需要把“准备周报”拆成收集数据、整理进展、格式化输出等多个子目标。

第二个特征是规划。规划不是简单地把一句话翻译成两步操作，而是基于当前信息决定“先做什么、后做什么、做不了时怎么办”。我给新人讲这个概念时经常用一个类比：Chatbot 就像超市货架前的导购员，你问什么他答什么；Agent 更像一个拿着购物清单的采购员，进了超市自己找货架、自己挑商品、自己结账，回来还会跟你对一遍账单。导购员能不能干活？能，但他的工作边界是“回答”；采购员的边界是“完成采购这个目标”。

第三个特征是行动。这里的行动不只是“输出一段文本”，而是调用真实工具产生可验证的结果：查询数据库、调用业务接口、发送通知、修改文件。没有行动能力的智能体，无论推理得多漂亮，都只是一个增强版聊天程序。我见过不少团队在规划阶段投入大量精力写思维链，却迟迟不肯接第一个工具接口，最后演示的时候只能靠口头模拟工具结果，这种 Demo 永远走不到生产环境。

1.3 闭环反馈：Agent 能不能自我修正

还有一点容易被忽略，却是 Agent 和普通多步调用的分水岭：闭环反馈。所谓闭环，就是 Agent 执行完一个动作后，能观察到这个动作带来的结果，再根据结果决定下一步行动。

完整的 Agent 循环通常长这样：接收输入（感知）→ 交给模型推理（思考）→ 选择并调用工具（行动）→ 把工具返回值重新喂给模型（观察）→ 继续推理直到输出最终答案。关键就在最后一步“观察”。如果工具返回的结果和预期不符，Agent 应该有能力调整策略、换个工具重试、或者如实告诉用户“这条路径走不通”。

我见过一个反面案例：某团队做了一个文档整理 Agent，它会按标题批量重命名文件。第一次测试时，工具返回的路径包含特殊字符，代码直接抛异常，Agent 却把异常信息原样当成“成功执行”的结果输出给用户。问题就出在这个团队没有实现观察环节，工具调完就把消息丢给模型，模型看到一段报错文本，不知道这是错误，还以为任务已经完成。所以，判断 Agent 是否合格，就去看看它的工具执行结果有没有被妥善加工并送回给模型，而不是被简单丢弃。

2. 搭一个最小可用 Agent：核心链路与骨架代码

2.1 先划清任务边界

很多人一上来就想做一个“什么都懂的全能助理”，这是失败最快的开局。我不建议这么做，原因很简单：Agent 不是搜索引擎，也不是自动驾驶，它需要在“什么能碰、什么不能碰、输出长什么样”这几件事上有明确边界。以我自己的经验，动手前先花半小时回答下面几个问题，能省下后面几天的返工。

第一，输入边界。用户给 Agent 的输入是自由文本、结构化表单，还是某个系统导出的文件？如果是自由文本，要不要先做意图识别？第二，输出边界。输出的结果是自然语言回复、JSON 数据、还是直接执行业务动作？第三，工具边界。Agent 能调用哪些系统，不能调用哪些系统？如果允许它发邮件、改库存、删文件，必须设置审批点。第四，失败边界。工具出错之后，Agent 是自动重试、换一条路，还是停下来问人？

我把这些边界写进第一版 Prompt 里，效果立竿见影。曾经有一版 Agent 在没有明确“不得删除”约束时，用户一句“清理测试数据”，它把几张关联表的数据一起清了。后来所有 Agent 的系统提示词里都固定出现一行：“只有用户明确要求且你具有对应权限时，才能执行删除类操作。”

2.2 三个基础部件

最小可用的 Agent 只需要三个部件：大模型、记忆、工具集。

大模型承担的是“大脑”功能：理解用户意图、生成任务规划、决定调用哪个工具、把工具结果组织成最终答案。目前的主流做法是让模型以“函数调用”或“工具调用”的方式输出结构化指令，再由代码去执行对应函数。这个设计比让模型直接生成代码再执行要安全得多，因为工具列表、参数结构、执行权限都被收拢在可控范围内。

记忆部件负责保存两类信息：一类是当前任务内的对话历史，另一类是跨任务的业务事实。最小版本只需要第一类，也就是把用户消息、模型回复、工具返回值按顺序存进一个消息列表，每一轮都整体传给模型。不需要一上来就上向量数据库，把简单事情先做扎实。

工具集是 Agent 能对外部世界产生影响的关键。最小工具集建议控制在五个以内，每个工具只做一件事。工具描述要写得像给新人看的工作说明：什么时候用、需要哪些参数、返回值是什么结构。我见过太多团队把工具描述写得含糊，模型判断不了该用哪个工具，最后出现各种奇怪调用。

2.3 能跑起来的最小骨架

下面这个骨架是我在多个项目里反复用过的简化版，不依赖任何特定框架，核心就是工具注册、消息循环、模型调用三件事。模型接口部分我做了抽象，实际接入任意大模型服务时，替换成对应的请求方式即可。

import json from typing import Any, Callable, Optional # ---------- 工具注册表 ---------- TOOLS: dict[str, dict[str, Any]] = {} def register_tool(name: str, description: str, parameters: dict): def decorator(func: Callable): TOOLS[name] = { "func": func, "description": description, "parameters": parameters, } return func return decorator @register_tool( "search_order", "按订单号查询订单状态，输入订单号，返回 JSON 字符串", { "type": "object", "properties": {"order_id": {"type": "string"}}, "required": ["order_id"], }, ) def search_order(order_id: str) -> str: # 这里对接你自己的业务系统 return json.dumps({"order_id": order_id, "status": "shipped", "eta": "2025-04-02"}) # ---------- Agent 主循环 ---------- class MinimalAgent: def __init__(self, model_client: Any, max_steps: int = 8): self.model = model_client self.max_steps = max_steps self.tool_schemas = [ { "name": name, "description": info["description"], "parameters": info["parameters"], } for name, info in TOOLS.items() ] def run(self, user_request: str, context: Optional[list[dict]] = None) -> str: messages = [ {"role": "system", "content": "你是任务执行助手，请根据用户需求调用可用工具，必要时可多次调用。"}, {"role": "user", "content": user_request}, ] if context: messages = context + messages for _ in range(self.max_steps): resp = self.model.chat( messages=messages, tools=self.tool_schemas, tool_choice="auto", ) msg = resp["message"] messages.append({"role": "assistant", "content": msg.get("content", "")}) tool_calls = msg.get("tool_calls") # 没有工具调用，认为已经完成 if not tool_calls: return msg.get("content", "") # 逐个执行模型发起的工具调用 for tc in tool_calls: name = tc["function"]["name"] arguments = json.loads(tc["function"]["arguments"]) messages.append({ "role": "tool", "tool_call_id": tc["id"], "content": self._execute_tool(name, arguments), }) return "已达最大步骤限制，请补充信息或等待人工介入。" def _execute_tool(self, name: str, arguments: dict) -> str: if name not in TOOLS: return json.dumps({"error": f"unknown tool: {name}"}, ensure_ascii=False) try: result = TOOLS[name]["func"](**arguments) return str(result) except Exception as exc: # 关键：把异常结构化返回给模型，而不是直接中断 return json.dumps({"error": str(exc)}, ensure_ascii=False)

这段代码最核心的地方有两个：一是tool_choice="auto"，把工具选择权交给模型，但执行权由代码控制；二是把工具执行结果和异常严格按照tool角色回传给模型，保证观察环节不丢失。很多初级实现会在抛出异常后直接结束流程，结果模型连自我修正的机会都没有。这个骨架跑通之后，再往里面加日志、权限校验、二次确认，都是顺理成章的事。

2.4 为什么这样简单的结构够用

有人会问：市面上不是有很多复杂的 Agent 编排框架吗？为什么先给这么简陋的一个循环？我的观点是，Agent 的复杂度应该有节制。大部分业务问题，比如客服工单处理、日程安排、内部知识检索，本质上都在“理解需求—查数据—给结果”这个范围内，一个循环加五个工具完全够用。

框架能帮我们省掉一些样板代码，但也带来不少隐性成本：抽象层过多，出了问题时排查链路变长；调度逻辑升级频繁，代码和框架版本容易脱节；外部依赖一多，安全边界需要额外防护。所以我建议先自建一个只有循环、工具注册、日志的最小系统，跑通一个真实任务后，再根据痛点决定是否引入框架。没有足够理由前，不要为“未来的扩展性”预支今天的复杂度。

3. 驾驭的关键：让 Agent 不乱跑、不撒谎、不瞎折腾

3.1 上下文管理：长对话不等于记忆

Agent 最容易翻车的点之一，是打着“有记忆”的旗号把所有消息都堆进上下文。模型输入窗口再大也是有限的，对话进行到二十轮之后，早期信息要么被截断，要么被大量工具返回内容淹没。更麻烦的是，每次请求都把全部历史发给模型，费用和延迟都会线性增长。我见过一个 Agent 处理三十分钟的对话后，单轮请求体积膨胀到原本的四倍，响应速度几乎不可用。

合理的做法是分级管理上下文：短期上下文只保留当前任务最近几轮对话；中期信息通过摘要压缩，每隔几轮把前面的内容用模型生成一段摘要；长期事实则抽出来写入结构化存储，需要时再检索。我在客服场景里实践过后，上下文体积稳定在初始大小的两倍以内，效果也没有明显下降。记住，上下文管理不是把更多文字塞给模型，而是让模型在有限的窗口里看到最相关的信息。

3.2 工具白名单：Agent 只能在“跑道”里行动

给 Agent 工具授权时，我遵循的原则是“最小权限，白名单制”。通俗地说，就像给实习生一张工作清单，而不是把公司门禁卡交给他。系统里有的工具可能很多，但单个 Agent 只需要暴露完成当前任务必要的三五个。权限越宽，出问题的概率越高，模型选错工具的后悔成本也越大。

工具描述本身也是一种约束。描述要写清楚使用前提、参数含义、返回结果和典型错误，最好还给一个或者两个示例。我见过一个 Agent 反复调用错误的工具，本质原因是两个工具描述太过相似：“创建用户”和“更新用户”就差一个词，模型经常混。后来我特意在描述里加了一句“当用户表示已有账号需要变更信息时，使用更新；首次创建时使用新增”，误调用的比例立刻降了下来。

对于发邮件、删除数据、修改生产配置这类有副作用的操作，我强烈建议加人工确认环节。具体做法是：Agent 在发起这类工具调用时，不直接执行，而是把待执行的动作展示给用户选“确认/取消”，等确认后才真正执行。虽然增加一步交互，但在真实业务中这个确认按钮能挡住大量潜在的“好心办坏事”。

3.3 输出校验：把幻觉拦截在交付前

大模型的一大毛病是“一本正经地胡说八道”，Agent 把这个毛病放大了，因为它的输出会被当成真实结果直接进入下游。应对办法只有一条：对所有关键输出做校验。

第一步是格式校验。如果 Agent 需要返回 JSON，就明确要求它返回一个符合预定义 Schema 的对象，再用程序解析校验，不合格的直接自动重试一次。第二步是业务规则校验。比如客服场景里要求订单号必须匹配ORD-开头加八位数字的格式，就用正则先查一遍；日期字段要落在合理范围内，就做范围判断。第三步是源数据复核，让模型在生成结论之前，先引用它所用到的工具返回记录，再由校验模块核对引用是否存在。

我把这套逻辑总结成一句话：不要相信模型的自我报告。模型说“已发送邮件”，不算数；必须把发送接口的真实返回值作为唯一依据。凡是无法用工具结果验证的内容，一律按未完成处理。这种强校验在早期会带来一些开发量，但它正是 Agent 能否从“演示”走向“生产”的分水岭。

3.4 打断与兜底：当好驾驶员

Agent 再怎么聪明，也只是一套软件系统，必须有外部给它踩刹车。我给 Agent 设的第一道刹车是max_steps，也就是单任务最大循环次数。第二道刹车是“重复检测”：如果模型连续两轮发起完全相同的工具调用、拿到相同结果，基本可以判定陷入死循环，应立即终止并要求人工介入。第三道刹车是超时控制，单个工具调用超过设定阈值就返回超时错误，让模型自己决定换路径还是放弃。

别忘了给用户留一个“打断”的入口。Agent 处于自主执行状态时，用户可以输入“停一下”“改方案”之类的指令，这需要代码每轮循环前检查是否有外部新消息进来。我一开始没做这个功能，测试时只能等 Agent 把流程跑完才能干预，体验很差。后来在循环入口加了一个消息队列检查，只要用户中途发来新指令，就立刻中断当前计划，把新指令作为最高优先级输入。记住，Agent 是替你执行任务，不该对你的判断形成阻碍。

4. 从 Hello World 到真实任务：一个完整的打磨案例

4.1 选场景：客服工单的自动分类与初步回复

挑选第一个真实场景时，我建议找“频率高、动作单一、容错可控”的任务。太复杂的场景会让问题定位变得困难，容错低的场景第一轮上线压力太大。我在这里拿“客服工单的自动分类与初步回复”举例，这是很多业务系统都需要的功能，也足够体现 Agent 的典型动作链。

假设工单系统每天收到上千条用户反馈，每条工单包含“标题”和“描述”两段文本。需要 Agent 做三件事：把工单分到四个类别之一（订单查询、售后服务、建议反馈、投诉）；判断优先级（高/中/低）；根据类别和内容草拟一段给用户的初步回复。历史积累了几千条已人工处理的工单，正好可以用来对比效果。

4.2 第一次尝试：一个“万能 Prompt”引发的崩盘

我的第一版实现极其天真：把分类规则、优先级规则、回复写作规范、示例数据全部塞进一个 Prompt，希望模型一次性输出完整结果。结果相当难看：分类准确率只有四成左右，输出的 JSON 经常缺字段或者格式错误，还有不少请求因为生成内容太多导致超时。整个反馈循环特别慢，每条工单浪费的 Tokens 也高得离谱。

复盘时意识到，问题不是模型不够聪明，而是我把太多认知负荷压在一次生成里。模型既要判断类别，又要判断优先级，还要构思回复语气，同时维护一个复杂的输出格式。任何一个环节出错，都会连带其他环节崩掉。这就像让一个新员工同时干接线员、投诉专员、质检员三份工作，不崩溃才怪。

4.3 拆成三步后，效果发生了质变

第二步实施的是“窄任务拆分”，把原来一大步拆成三个顺序步骤，每步只做一件事。第一步做分类，Prompt 只让模型输出一个类别值，可选枚举写得很明确，并附上每类两个历史工单作为示例。例如：

请把以下工单分到四个类别之一，只能输出 JSON：{"category": "order_query | after_sale | suggestion | complaint"} 工单标题：{title} 工单描述：{description} 示例1：标题“发货后一直没物流更新”，描述“订单显示已发货三天，物流一直停留在原地”，结果：{"category": "order_query"} 示例2：标题“包装破损”，描述“收到的箱子已经被压坏，里面的产品也有划痕”，结果：{"category": "after_sale"}

第二步做优先级判断。这一步不再重新阅读原始工单全文，而是把第一步的类别、工单标题以及一些关键信号词（比如“两次”“加急”“破损”等）作为输入，让模型只输出高/中/低三档。第三步生成回复草稿时，先使用工具查询该工单关联的订单信息，再把订单数据和前两步的分类结果一起放进模板，生成一段带占位符的回复，由程序负责填充真实订单号等信息。

三个窄步骤分别做质量验证后，分类准确率从最初的四成提高到了八成六，JSON 格式合规率接近百分之百，整体耗时反而下降了五分之一。更让我意外的是，因为每步输出都在受控范围内，出问题时定位特别快：分类错了查第一步，优先级不对查第二步，不会出现“整体结果很怪但不知道怪在哪”的局面。

4.4 Prompt 模板写法与参数调优

经过这个案例，我总结了一套适合 Agent 内嵌任务的 Prompt 写法。第一，输出格式优先：无论什么任务，都在开头就写明“只输出符合 XX Schema 的 JSON”，例如{"category": "order_query | after_sale | suggestion | complaint"}，比不加约束的自然语言容易解析得多。第二，枚举值要给全：用竖线或分隔符把所有候选值列出来，不要写“根据内容判断类型”这种模糊指令。第三，用少量高质量示例：每个类别给两个左右的真实样例，比给二十个相似样例更有效，质量永远比数量重要。

参数调优方面，我基本固定为：分类、提取这类确定性任务，temperature设置为 0 或 0.1；生成回复内容的步骤，可以放宽到 0.3 到 0.5，但绝不超过 0.7，否则语气会飘。max_tokens建议按步骤分别设置，分类步骤给很小额度，回复生成步骤给充足额度。还有一条容易被忽略：每个步骤之间最好用程序做字段校验，不合格就让模型基于错误信息重试一次。无限重试是最容易失控的配置，最多重试两次就要转入人工。

5. 真实运行中的成本、速度与故障排查

5.1 Token 耗在哪：你可能没注意的隐性开销

上线前我估算过成本，自以为对每次调用的 Token 量心里有数。结果跑到第三天的账单还是让我清醒过来：Agent 的 Token 消耗远不是“平均请求长度乘以次数”那么简单的估算，它有三个隐藏开销容易被忽略。

第一个是工具描述的系统开销。每轮循环都会把工具 Schema 跟着请求发过去，工具一多，描述一长，这部分的 Token 是固定的，不随业务变化。假设五个工具的描述加示例共八百个 Token，十步循环就是八千个，完全不可忽略。第二个是工具返回结果的重放开销。模型每轮都要重新看到上一轮工具返回的内容，如果某个工具返回了一个几万字符的日志，后面的每一步都在帮它重复计费。第三个是历史消息的累加效应。带上下文的长对话会让每一轮请求越来越长，越到后面费用越高。

对策也很直接：工具描述尽量精简到一句话内，参数枚举用关键字而不是长句子；工具返回结果在使用前先截断，只保留最关键字段，再塞进消息；对历史对话做摘要，早于某个窗口的消息压缩成一小段小结。我按这三条做了一轮优化，同样业务量的 Token 成本大概压低了四成。

5.2 速度瓶颈：模型推理 vs 外部服务

速度优化要先知道瓶颈在哪。我做过一次简易埋点，把一次工单处理任务拆成三段时间：模型等待时间、工具执行时间、校验时间。数据分布大致是：模型占百分之六十，工具占百分之三十，校验占百分之十。这个分布在不同业务里会变，但模型等待时间几乎总是大头，所以想提速度时，先别急着让外部接口“变快”，先看看能不能减少模型交互次数。

减少模型调用的常见办法是批处理：把好几个独立工具请求合并成一轮调用，让模型一次性发起多个工具调用，然后并行执行。另一个办法是给常见问答做精确缓存：如果用户请求和过去某个请求完全一致，直接返回缓存结果，不浪费一次模型调用。缓存命中率做得好，平均响应时间能降一半以上。还有一点，工具调用如果真的耗时太长，可以考虑异步化：先把任务进度返回给用户，等工具结果出来后再推送最终结果，避免用户在屏幕前干等。

5.3 怎么给 Agent 排错

Agent 项目上线后最折磨人的不是开发，而是排错。传统程序出错有堆栈、有日志，Agent 出错常常表现为“结果看起来合理但实际上跑偏”或者“某个环节悄悄失败”。我后来养成了一个固定排错流程，每次出问题都按这个顺序走，效率会高很多。

第一步，找到那一次的完整消息序列。需要看到从用户输入、模型每一轮的完整输出、每个工具请求和返回值一直到最终结果，缺任何一环都无法定位。第二步，定位是哪一类错误。我把常见错误先分了四类，如下表所示。

第三步，把定位到的问题转成新的约束，写进 Prompt 或校验逻辑。排错不是修完就完，要把这次教训沉淀成一条规则，比如“凡是涉及订单号的回答，必须先调用查询工具，禁止直接生成订单状态”。按这个流程跑下来，我基本能在半小时内定位大多数线上问题，而不再像早期那样靠蒙。

5.4 给 Agent 装“黑匣子”：日志与可观测性

Agent 的排查难点在于它是多步、多工具的，传统的行日志根本不够用。我的建议是给每次完整任务生成一个唯一的追踪 ID，然后把所有日志串联起来。每一条结构化日志至少要包含这些字段：时间戳、追踪 ID、步骤序号、事件类型、涉及的模型 Tokens、工具名称、耗时、消息摘要。

还有一个账号长期用起来最舒服的日志配置：把每一步的“模型发起工具调用参数”“工具返回结果的前若干字符”都记录到文件，必要时候还要把完整消息序列快照保存，方便回溯。我习惯给每种事件单独记一条 JSON 日志，而不是塞进普通文本日志里，这样写检索脚本特别方便。上线后我还设了几个基础告警：平均响应时间超过阈值、单任务 Token 消耗超过阈值、工具错误率超过阈值，加起来基本能做到“有故障先不慌，看日志定位”。

6. 更复杂的玩法我为什么不急着上：多 Agent 与长期记忆

6.1 什么时候才需要多 Agent

在社区讨论里，多 Agent 编排总是显得很酷，但真实业务里能用上它的场景其实不多。我判断“要不要上多 Agent”的标准很朴素：单 Agent 的上下文是不是已经被互相干扰的任务塞满了？不同子任务之间是否需要隔离权限？子任务的失败是否可以互不影响？只有这些答案为“是”，才值得考虑。

举个例子：一个自动生成营销内容的系统，可能包含“市场数据查询”“内容创作”“合规审核”三类职责。如果让同一个 Agent 既查数据又写文案又做审核，它很可能在写文案时受到查询内容的干扰，或者在审核时因为和作者共享同一套上下文而“护短”。拆成三个 Agent 后，数据 Agent 只负责输出结构化数据，内容 Agent 只管写作，审核 Agent 只做合规判断，每个 Agent 的 Prompt 更简短，权限也能分别收紧。这是多 Agent 架构最有价值的场景。

6.2 两种协作模式：主从编排 vs 协商式

多 Agent 的协作模式大致分两类：主从编排和协商式。主从编排是一个主管 Agent 负责拆解任务、分配子任务、汇总结果，子 Agent 只听从安排，不互相沟通。这种模式结构清晰，适合流程固定的业务，也容易做日志跟踪。缺点是主 Agent 本身会成为新的瓶颈，它的规划和调度质量决定了整个系统的表现。

协商式则是多个 Agent 共享一个“任务黑板”，轮流阅读和补充内容，通过多轮交流逐渐收敛到最终方案。这种模式更接近人类团队的协作方式，能处理更开放的创造性任务，但风险和成本都高得多：对话轮数不固定，每个 Agent 都可能偏离主题，Token 消耗也成倍增长。我目前只在探索项目里用过协商式，生产系统里一律采用主从编排，原因很简单：可预测性和可控性比花哨的协作机制重要得多。

6.3 长期记忆的三种姿势

不少团队一上来就想给 Agent 做长期记忆，动不动就要上向量数据库。我的经验是，长期记忆至少有三条路，选哪条取决于业务真正需要什么。第一是向量检索引擎，适合“按语义找相似内容”的场景，比如在历史工单库里找类似问题的解法，效果不错，但对事实类查询不够精确，检索结果还经常夹带噪音。第二是结构化存储，把订单、用户、产品这类事实放进传统数据库，查询时用工具接口访问，精确但需要人工定义数据模型。第三是摘要归档，就是把每次都生成一份任务摘要存起来，下次遇到相似任务时可以快速参考，实现最简单，但会丢失细节。

给一个务实的建议：先把短期上下文管好，把工具结果保存好，等发现非跨会话记忆不可的时候，再开始做长期记忆。过早引入复杂的记忆系统，大概率会在检索质量问题上浪费大量时间，而核心业务价值未必有提升。

6.4 我为什么刻意保持“克制”

带过几个 Agent 项目后，我越来越认同一个观点：克制是复杂度控制的重要原则。单一 Agent 能搞定的任务，不拆；短期上下文能承载的信息，不存长期；一个循环加几个工具能解决的业务，不上框架；规则校验能兜底的风险，不指望模型自觉。这个原则让我少踩了很多坑。

尤其在生产环境里，性能稳定、成本可控、错误可解释，这三件事比“看起来智能”重要得多。我的做法是让 Agent 在约束范围内跳舞：给它清晰目标、给它白名单工具、给它强校验、再给它刹车。模型负责发挥灵活性的部分，规则负责兜住风险的部分，两者配合得越默契，系统才越接近“好用”的状态。

我个人在实际项目里反复验证过的结论是：先约束，再赋能；先单 Agent 跑通，再加多 Agent。任何一个看起来失控的 Agent，多半不是模型不够聪明，而是我们没给它划清楚跑道。如果你正准备动手做一个 Agent，建议从最小骨架开始，先把循环跑通，再把工具接上，最后加上校验和日志，一步步稳着来。等你经历过一次从“演示惊艳”到“上线翻车”再到“逐步修稳”的完整周期，你会更理解什么叫驾驶一辆智能体——方向盘始终要握在自己手里。