企业官网建设流程全解析

1. 工具调用格式失控：解析链路上的暗雷

做 agent 的朋友都懂，最让人抓狂的不是模型答错题，而是模型“答对了但格式错了”。你说好了返回 JSON，它给你夹带 Markdown；你说好了用action字段，它给你换成Action；更有甚者，在工具参数里直接写自然语言“请帮我查一下北京的天气”，而不是结构化参数{"city": "北京", "date": "2025-01-06"}。

这个问题我在实际项目里栽过不止一次，必须放在最前面讲，因为它是 agent 一切后续逻辑的地基。很多刚上手中控框架的团队，第一周几乎都在跟格式问题搏斗。

1.1 隐藏的触发器与共性解法

把不同项目里的报错样本收敛一下，会发现格式失控几乎都发生在三类场景里：

• 系统提示词里同时塞入了“工具描述”“输出示例”“少样本问答”三段内容，模型被示例带偏，学会了“多余的前缀后缀”。
• 工具返回结果里残留了异常字符（比如某个数据库字段带了换行符和引号），模型为了“忠实于原文”，把这些脏字符一起复制进了下一次工具参数。
• 长上下文场景下格式漂移，前面几轮都用对了，到第五轮忽然夹带了一段思考过程。

针对这些问题，我目前实测下来最稳的方案是三重校验，缺一不可：

第一重，强制工具调用走独立的tool_calls通道，而不是让模型把参数写进普通对话文本里。市面上的主流模型 API 都原生支持这种结构化的工具调用方式，你只要在请求里声明工具列表，模型会在独立的字段里返回结构化的参数，天然避开“夹带多余内容”的问题。这一层能挡掉大概 80% 的格式错误，成本极低。

第二重，JSON 解析失败后不做“二次启发式修复”，而是直接重试。很多框架会自作主张去“补全残缺 JSON”，比如自动在末尾补一个}，或者把单引号替换成双引号。我的经验是：宁可让 agent 多调用一次模型，也不要在解析层做这种投机取巧的修复。因为你修复出来的参数大概率是错的，而模型下一次重新生成时自己会意识到问题，产出正确参数的概率反而高得多。

第三重，对关键参数做最终的类型与取值校验。比如日期字段必须匹配\d{4}-\d{2}-\d{2}，枚举字段必须在预设列表中。这层校验不依赖模型，纯粹是确定性逻辑，能在工具真正执行前再兜一次底。

1.2 建立可观测的失败样本池

解决格式问题不能靠“改了再试”，你得有数据。我在项目里做了一个非常轻量的事情：把所有解析失败、重试成功、重试仍失败的请求都落成结构化日志，字段包含模型返回的原始文本、解析期望格式、失败原因分类、重试次数和最终结果。

这样跑一周之后，你会发现格式问题根本不像想象中那么随机。某些模型在特定温度参数下格式漂移率明显更高；某些复杂工具（参数超过 8 个的那个）出错率是简单工具的 3 倍。这些结论不靠日志你永远没法量化。有了这个失败样本池之后，你就可以针对性地做两件事：一是把最高频出错的工具描述改写得更简洁，二是给复杂工具增加“参数默认值”，减少模型必须输出的字段数量。

2. 上下文管理失效：窗口不是垃圾桶

“给 agent 塞了多少上下文，决定了它上限有多高，也决定了它下限有多低。”这句话在实践中经常被极端化理解——有人恨不得把整个知识库都塞进上下文，也有人因为怕超限而砍掉关键信息。两种极端都很危险。

上下文管理失效的症状很典型：agent 在用完窗口边缘的数据时开始“胡言乱语”，复述早期内容，或者干脆忽略系统提示词中的硬性指令。原因大家都猜到了，就是大模型对长上下文中间段的注意力会明显衰减，不过真正让人头疼的是“衰减”不是平滑的，而是呈现一种“中间断层”的模式。

2.1 窗口预算的分层分配策略

我自己用下来最顺手的分配方式，是把窗口想象成一间三居室，而不是一个垃圾桶：

核心思路是：系统指令区永远保留最精简的版本，用“不要做什么”取代“要做什么”的冗长罗列；工作区只保留当前任务链相关的中间结果，更早的内容降级为摘要；边缘区内容随用随取，用完之后立即从工作区移出。

关于摘要降级，不是简单让模型用一句话总结上一轮对话，而是按照“任务目标→已执行步骤→关键结论→遗留问题”四段式来生成摘要。这样即使历史内容被压缩成几百个字，agent 在执行后续步骤时依然能找到自己“进行到哪一步了”的锚点。

2.2 截断顺序与关键内容保护

需要主动截断时，一定要遵循“先截工具输出，再截历史对话，最后截系统提示词”的顺序。原因很好理解：工具输出的体量往往最大，但大多数属于“用过即弃”的过程性数据；历史对话里保留了用户意图的演进过程，价值比工具输出高一档；而系统提示词是行为基线，万万不可动。

实操层面还有一个容易忽略的细节：截断时不要只按 Token 数切，要按“语义完整块”切。比如某个工具调用包含一条用户的原始问题、一次工具返回、一次模型的分析结论，这三者要作为一个整体保留或移出，不要单独切断工具返回。一旦切碎了，后续轮到模型分析时，它会面对一份没有前因后果的孤立数据，很容易产生错误解读。

3. 记忆机制的分叉与污染：串味比遗忘更可怕

如果说上下文管理是“内存”问题，那记忆机制就是“磁盘”问题——它决定了 agent 能跨会话记住什么、忘掉什么。这一块的问题有两个极端：一个是“记不住”，另一个是“记太乱”。

“记不住”好理解，就是每次新会话 agent 都像失忆一样问你重复的问题。这个问题的解法相对成熟，无非是做外部记忆库，按会话 ID 存取摘要。真正让我头疼的是第二个：记忆污染。所谓污染，指的是 agent 把某一次对话里的暂时性状态（比如“用户今天心情不好”或“当前任务遇到阻塞”）当成了用户的长期偏好，写进了长期记忆库，然后在未来的所有会话中都带着这份偏见做决策。

3.1 区分短期状态与长期画像

这个问题的根源在于记忆写入时没有分类。我现在要求记忆写入必须带标签，至少分为三类：

• episodic（情景记忆）：某一次会话中发生了什么，适用于单次任务的连续执行。
• semantic（语义记忆）：从对话中提炼出的用户偏好、事实结论、领域知识，适用于跨会话复用。
• procedural（流程记忆）：用户希望 agent 在处理某类任务时遵循的习惯性流程，比如“周报要用表格”“回复要附原文链接”。

写入规则也很明确：情景记忆默认只保留 7 天或者随会话销毁；语义记忆写入前必须经过一次“去情景化”校验——问一句“如果用户明天看到这条记忆，他会觉得这仍然成立吗？”；流程记忆的写入需要更审慎，要求必须见到同类行为至少两次才能沉淀为流程，只出现一次的不算。

3.2 让记忆“可删除”比“可写入”更重要

实际项目里，记忆系统最大的工程质量问题不是写入，而是删除。用户明确说“以后别再这样了”，agent 说好好好，但下次回来它还是老样子——因为记忆库里根本没有提供删除和修改的入口，或者虽然有入口，但记忆条目没有关联来源，无法定位到具体是哪一次的哪句话生成了这条记忆。

这个问题的工程解法是，每一条长期记忆生成时必须带回源指针：来源会话 ID、原文摘录、可信度评分。有了源指针之后，删改就不再是改一条孤立记录了，而是“从用户反馈反查到来源对话，再回到记忆条目上做变更”，形成一条完整闭环。我在团队里反复强调：记忆库的表结构设计，从第一天起就要考虑“谁创建了这条记录”“依据是什么”“怎么反查”，否则三个月后它会变成一笔算不清的烂账。

4. 工具选择错误与参数幻觉：模型在“不懂装懂”

agent 和普通聊天机器人的最大差异在于“执行力”，而执行力最直接的体现就是工具调用的准确性。不过大家普遍反馈，模型在选择工具时经常“犯错”，错误集中在两处：一是工具选错，二是在参数里编造不存在的选项。

一个非常经典的案例：某项目里给 agent 挂了一个天气查询工具、一个穿衣建议工具，结果用户问“明天去上海出差要带什么衣服”，模型直接调用了天气查询工具并传参{"days": "明天"}，然后基于查询结果自己“推算”穿衣建议。如果当时没有把穿衣建议工具挂上去，这个方案看起来还挺顺理成章的，但既然工具列表里明明有“穿衣建议”这个更贴切的选项，模型这种绕路行为依然让人费解。

4.1 参数幻觉在 RAG 类工具中特别高发

参数幻觉在数据库查询类、RAG 检索类工具上尤其严重。原因在于这类工具的入参通常是“语义检索关键字”，而模型在生成关键字时会把对话上下文里出现过的专有名词随意拼凑。比如用户明明只提到“上个月的项目”，模型在调 RAG 工具时会自作主张加上“成本超支”这种从未出现过的限定词，导致检索结果被过滤到几乎为空。

应对方面，我实测下来最有效的办法是把 RAG 工具的入参从“自由文本”改成“结构化枚举结合自由补充”：固定字段用枚举值（时间范围确定性写成选项），自由补充字段限制最长 20 字并明确提示“只能使用用户原话中的词语，禁止自行添加修饰词”。这招虽然牺牲了灵活性，但检索准确率的提升非常明显。

4.2 关键执行前的不可逆操作复核

另外一个必须做的事，是对“不可逆操作”执行前增加一道用户确认。这里指的不仅是删除、转账、发送邮件这类高成本动作，还包括那些“执行了很难撤销”的工具，比如覆盖一份文件、给所有群发消息、创建一条对外发布的内容。实现方式就是给工具加一个requires_confirmation元字段，agent 在执行前必须先输出一次待确认摘要，等用户明确同意后再真正触发工具。别嫌多此一举，在用户可感知的高成本场景中，一次误操作对信任的伤害远大于多一步确认带来的交互负担。

5. 循环、死锁与失控递归：当 agent 走不出来时

如果说前面的问题都是“质量”问题，那这一步就是“事故”问题。循环与失控递归是 agent 在生产环境里最让人头秃的表现：同一个工具被调用几十次、陷入反复重试、把单次任务的调用量烧到几百次还是没结果。这类问题往往不是模型单独造成的，更多是工程架构没做护栏。

5.1 三步收敛循环的终止条件设计

打破循环的设计其实不复杂，核心是给 agent 的每一步行动加上“确定性护栏”。我通常实现三层：

• 调用次数上限：单个任务最多允许 N 次工具调用（根据任务复杂度定，我常用 10~15 次），超了强制转入“汇报当前状态，请求用户指导”的收尾流程。
• 重复动作检测：如果模型调用了同一个工具且传参完全相同（或高度相似）超过两次，直接中断，并主动提示“这个方案已经尝试过，请更换思路或请求用户确认”。
• 收益评估节点：每完成三次工具调用，追加一次中间评估：“目前离目标还有多远？是否需要调整方案？”这一步的价值在于，让模型自己发现当前路线走不通，而不是闷头把 15 次调用全部烧完。

很多人以为循环问题是模型“傻”，但实测下来，有很大比例是“提示词里没有告诉模型什么时候该停下来”。你在系统提示词里白纸黑字写清楚“如果连续两次工具调用返回结果没有新增有效信息，必须停下并总结现状”，循环率能肉眼可见地下降。

5.2 子 agent 的任务归属与退出协议

多 agent 协作场景里的死锁就更隐蔽了。当主控 agent 把某子任务委托给子 agent 后，常见的失控形态是：子 agent 完成不了任务但又不归还控制权，一直在内部尝试；主控 agent 等不到结果，又不敢继续后续步骤，两边僵住。

这个问题的根源在于没有定义“任务退出协议”。我最初只定义了“子 agent 用 finalize 工具结束任务”，结果它遇到完不成的活儿时干脆不调用，让主控一直空等。改进方案是给子 agent 增加一个明确的退出条件和超时兜底：当子任务执行超过预设轮数或时间，主动返回“未完成原因＋已获取的部分成果＋建议下一步由主控处理”。这样即使子 agent 失败了，主控也能基于它带回的部分结果继续推进，不至于整条任务链断掉。

6. 多 agent 协作中的消息风暴与角色错位

最后一个值得重点讨论的问题是复杂场景中的多 agent 编排。多 agent 不是“多个单 agent 的简单拼接”，当你真正让几个各司其职的 agent 协作时，第一个遇到的经典问题就是消息风暴。

6.1 核心日志保留与噪音截断

我见过的情况是这样的：主控 agent 在推进一个跨部门任务时，触发了市场调研 agent、竞品分析 agent、文案生成 agent 三个子任务，子 agent 之间又各自向主控汇报中间进度。由于没有全局协调，主控在同一时刻收到七八条消息，上下文瞬间被打爆。更离谱的是，主控 agent 还经常在中间被一些“进度汇报型”消息带跑，把注意力从任务目标转移到查询子 agent 的细节工作上。

这个问题的解法，是给多 agent 协作加上“消息分级”机制。主控与子 agent 之间只允许传递以下三类消息：任务下发（含明确的目标和交付物标准）、结果回传（含最终产出或无法完成的说明）、异常上报（仅限无法自行决策的阻塞）。除此之外，所有“过程进展”“中间思考”“额外发现”一律写入共享的状态存储区，主控不主动订阅，需要时再按需读取。

这么说可能有点抽象，打个比方：子 agent 像一个外包团队，你只需要它交付成果、报告阻塞、说明延期，它不需要每分钟跟你同步“我正在写第二段”。如果你不加约束，agent 之间也天然倾向于过度同步，因为模型总觉得尽报详情是一种负责任的表现，最终结果就是把上下文塞爆。

6.2 基于角色隔离解决责任悬空

角色错位是另一个容易被忽略的坑。典型场景是：文案生成 agent 在生成内容时，发现需要参考一份数据报表，它直接调用了一个数据查询工具（这个工具原本被预设为主控专用），结果查询条件不完整，返回的数据用不上，白消费一次调用，还让主控以为“文案 agent 卡在数据上”，误判了瓶颈。

我在设计协作架构时，现在会在发起每个子 agent 时明确用系统提示词声明它的工具白名单，超出白名单的工具一律不在它的可调用列表里出现。同时在提示词里写清楚“你需要查看数据时，将需求描述为『请求主控提供数据』，而不是自行调用未授权的工具”，让子 agent 把“自行解决”的冲动转换为“请求协作”的正确行为。这算是一种角色隔离原则的落地。

7. 一个更隐蔽的问题：评估缺失比缺陷本身更致命

最后这点是我最想跟同行们分享的。上面的所有问题单拎出来都有解法，真正让人反复吃瘪的原因，是团队里没有一套评估体系，导致每次优化都像盲人摸象。你改了上下文策略，是变好了还是变差了？你调整了工具描述，是不是顺便把另一个场景搞坏了？如果没有评估，这些问题永远没有答案。

7.1 轻量级评测集的建设思路

很多人一听“评测集”就本能地觉得是个大工程，需要标注大量数据，还要搭一个复杂的评估流水线。其实你可以也从最小闭环起步：拿最近一周的真实用户会话，人工挑出 30~50 个有代表性的任务场景，每个场景标注好“期望调用哪些工具”“期望产出什么结果”“哪些行为属于必须避免的禁区”。

然后把这些场景作为固定输入，每次改动 prompt 或工具配置之后，全量跑一遍，比较改动前后的工具选择准确率、任务完成率、平均调用次数、上下文消耗量。这四组数字的变化幅度就是你这次改动真实效果的量化指标。有了这套东西之后，优化就不再是拍脑袋了，你能明确知道哪一次改动是正向的、哪一次是负向的，团队里吵架的概率也直线下降。

7.2 把“失败路径”纳入评审视野

另外评测场景不要只挑“正常任务”，一定要包含失败路径。我每次建评测集都刻意准备 10% 左右的“用户表达模糊”“工具返回异常”“同一问题多轮追问”的案例，专门考察 agent 在异常场景下还能不能保持冷静和遵守流程。坦白讲，agent 在正常路径上表现再好，遇到一次异常就开始胡言乱语，在真实用户面前依然是不可用的。

结合实践，我认为 agent 开发里最值得敬畏的事不是模型能力，而是工程护栏的完备程度。格式校验、上下水分层、记忆分类、循环终止、消息分级、评估闭环——每一层都不是多么花哨的技术，但每一层都决定了一个 agent 项目是能长期稳定运行，还是只会停留在 Demo 阶段。而评估闭环，恰恰又是这些工程能力能持续优化的前提。想把这个方向做扎实的同学，我建议的路径是：先建评测集，再逐层补护栏，每补一层都用评测集验证效果。顺序反过来做，很容易陷入“修了一个 bug，引入三个新 bug”的怪圈。