1. 企业买了工具，为什么 AI 还是没落地
1.1 一个很常见的尴尬场景
我最近半年跑了七八家企业做 AI 落地咨询，几乎每一家都遇到过同一个场景：老板拍板买了 Codex 的企业席位，又给团队配了 WorkBuddy 的工作台，预算批了、账号开了、培训也做了，结果三个月后我去回访，发现真正每天在用的不超过三个人。剩下的同事要么觉得"这东西跟我业务没关系"，要么试了两次发现输出不对就放弃了。
这个现象不是工具的问题。Codex 作为命令行编码 Agent，在代码生成、重构、脚本编写上的能力是实打实的；WorkBuddy 作为工作台类产品，在任务编排、多 Agent 协作、流程自动化上也有完整的框架。问题出在中间那一层——通用工具和企业具体业务之间，缺了一个"翻译层"。
这个翻译层，就是我今天想聊的核心：用 FDE（Forward Deployed Engineer，前置交付工程师）的思路，配合 AKA（Agent Knowledge Architecture，Agent 知识架构）的方法，把买来的通用 AI 能力，深度定制成企业自己业务里能跑起来的东西。
1.2 谁适合看这篇内容
如果你是企业里的技术负责人、AI 落地推动者、或者被老板指派"把 AI 用起来"的那个人，这篇内容就是写给你的。我不打算讲空泛的方法论，而是把我在实际项目里踩过的坑、用过的配置、跑通的流程，一条一条拆开讲。
如果你只是个人开发者想玩玩 Codex，这篇可能有点重，但里面关于 Agent 架构、知识注入、上下文管理的部分，对你同样有参考价值。因为个人用和企业用，底层逻辑是一样的，只是企业多了权限、合规、协作这几层约束。
1.3 先厘清几个概念，不然后面会晕
在往下走之前，我把几个关键词用大白话解释一遍，避免后面反复绕。
Codex在这里指的是命令行形态的编码 Agent，它能读你的代码库、执行命令、生成补丁。它的强项是"在代码上下文里干活"，弱项是"不知道你公司的业务规则"。
WorkBuddy是工作台形态的 Agent 编排平台，它能把多个 Agent 串起来，做任务分发、结果汇总。它的强项是"流程编排"，弱项是"每个环节的领域知识需要你自己灌"。
FDE原本是 To B 交付里的一个角色定位——工程师直接驻场到客户业务里，把产品改造成客户能用的样子。放到 AI 落地里，FDE 的职责就是：把通用 Agent 改造成懂这家公司业务的 Agent。
AKA是我自己总结的一套方法，全称 Agent Knowledge Architecture，核心就一句话：把企业知识拆成 Agent 能吃的粒度，分层喂进去。后面会详细展开。
Agent就是能自主执行任务的 AI 程序，它和普通聊天机器人的区别在于：Agent 有目标、有工具、有记忆、能多步执行。
把这五个词串起来就是：用 FDE 的角色思路，通过 AKA 的方法，把 Codex 和 WorkBuddy 这类通用 Agent 工具，定制成企业业务里真正能跑的 Agent 系统。
2. 通用 Agent 落地失败的四个真实原因
2.1 原因一：知识没有分层，全塞进提示词
我见过最典型的错误做法，是把公司所有的规章制度、业务文档、代码规范，一股脑塞进系统提示词里。结果就是提示词长到几万字，模型注意力被稀释，真正关键的信息反而被淹没。
这就像你给新员工一本一千页的手册，让他第一天就全部记住。他记不住，Agent 也记不住。正确的做法是分层：常驻层放最高频的规则，检索层放按需查询的知识，工具层放需要实时获取的数据。这个分层逻辑，就是 AKA 的核心。
2.2 原因二：没有业务上下文，Agent 只会说正确的废话
通用 Agent 最大的问题是"政治正确但没用"。你问它"这个订单能不能退款"，它会给你一段标准的退款政策说明，但它不知道你们公司这个客户是 VIP、这笔订单已经超期、当前库存状态如何。
Agent 要落地，必须能拿到业务系统的实时数据。这就需要在 Agent 和业务系统之间搭一层工具接口，让 Agent 能调用查询、能触发动作。Codex 在这方面有天然优势，因为它本来就能执行命令、调用脚本，你只要把业务查询封装成脚本，它就能用。
2.3 原因三：权限和合规没人管，IT 部门直接叫停
这个坑我踩过。有个项目做到一半，IT 安全部门发现 Agent 能读取生产数据库，直接一纸通知停掉了整个项目。后来我们重新设计，把 Agent 的权限收敛到只读视图、脱敏字段、审计日志三个约束里，才重新上线。
企业级 Agent 和玩具 Agent 的分水岭，就是权限设计。你在个人环境里可以让 Agent 随便跑，但在企业里，每一个工具调用都要能追溯到"谁、在什么时间、对什么数据、做了什么操作"。
2.4 原因四：没有反馈闭环，Agent 越用越笨
很多企业上线 Agent 后就撒手不管了，用户反馈的问题没人收集，Agent 答错的案例没人整理，结果就是同一个错误反复出现。
Agent 的进化靠的是反馈数据。你需要建立一个机制：用户对 Agent 输出不满意时，能一键标记；每周有人把这些标记整理成新的知识条目或修正规则；这些修正再回流到 AKA 的知识层里。没有这个闭环，Agent 就是个一次性产品。
3. AKA 方法：把企业知识拆成 Agent 能吃的粒度
3.1 AKA 的四层结构
AKA 的核心是把企业知识分成四层，每层用不同的方式注入 Agent。我用一个表格说清楚。
| 层级 | 内容类型 | 注入方式 | 更新频率 | 典型例子 |
|---|---|---|---|---|
| L1 常驻层 | 最高频、最核心的规则 | 系统提示词 | 季度 | 代码规范、命名约定、安全红线 |
| L2 检索层 | 大量文档、历史案例 | 向量检索 | 周 | 产品文档、FAQ、历史工单 |
| L3 工具层 | 实时数据、业务动作 | 函数调用 | 实时 | 订单查询、库存接口、审批触发 |
| L4 记忆层 | 会话上下文、用户偏好 | 会话存储 | 每次对话 | 用户历史、项目状态 |
这个分层的逻辑是：越靠上的层，越稳定、越通用；越靠下的层，越动态、越个性化。L1 是骨架，L4 是血肉，中间两层是连接。
3.2 L1 常驻层怎么写才有效
L1 层最容易写砸。我见过有人把 L1 写成了一篇论文，也有人写成了一句话。我的经验是：L1 控制在 800 到 1500 字之间，用条目式，每条不超过三行。
写 L1 的时候，你要问自己三个问题：这条规则是不是每次对话都适用？这条规则是不是违反了会出大问题？这条规则能不能用一句话说清楚？三个都是"是"，才放进 L1。
举个例子，一个电商公司的 L1 可能长这样：
你是本公司的业务助手，遵循以下核心规则： 1. 涉及价格、库存、订单状态的回答，必须调用工具查询实时数据，不得凭记忆回答。 2. 涉及退款、赔付、优惠券发放的操作，必须提示用户确认，不得自动执行。 3. 对外输出的所有内容，不得包含内部系统名称、数据库字段名、员工真实姓名。 4. 遇到无法确定的问题，明确说"我需要查询后回复"，不得编造。这四条规则，每一条都是"每次适用、违反出大事、一句话说清"。这就是合格的 L1。
3.3 L2 检索层怎么建才不翻车
L2 层是向量检索，坑最多。我总结下来有三个关键点。
第一，切块粒度要按语义切，不要按字数切。很多人图省事，按 500 字一刀切，结果一个完整的流程被切成两半，检索出来的是半截信息。正确做法是按文档结构切，一个章节、一个 FAQ 条目、一个工单闭环，作为一个块。
第二，每个块要带元数据。元数据包括来源、更新时间、适用部门、置信度。检索的时候可以按元数据过滤，比如只检索"最近半年更新"且"适用技术部"的内容。
第三，检索结果要重排序。向量相似度只是初筛，真正决定质量的是重排序。我一般用"相似度 + 时效性 + 来源权威度"三个维度加权，权重根据业务调。
3.4 L3 工具层怎么设计才安全
L3 层是 Agent 和业务系统的接口，也是最容易出安全问题的地方。我的设计原则是最小权限 + 白名单 + 审计。
最小权限的意思是，Agent 能查订单，但只能查脱敏后的订单摘要，不能查完整客户信息。白名单的意思是，Agent 能调用的接口是预先注册的，不能动态发现新接口。审计的意思是，每次调用都记录日志，包括调用者、参数、返回、时间。
在 Codex 里实现 L3，我一般把业务接口封装成命令行脚本，放在一个专门的目录里，然后在 L1 里告诉 Agent"只能调用这个目录下的脚本"。这样既利用了 Codex 执行命令的能力，又限制了它的活动范围。
3.5 L4 记忆层怎么用才不失控
L4 层是会话记忆，用得好能大幅提升体验，用不好会泄露隐私、污染上下文。我的做法是分级记忆：短期记忆只保留当前会话，长期记忆只保留用户明确确认过的偏好，敏感信息一律不记忆。
具体实现上，短期记忆用会话 ID 关联，长期记忆用用户 ID 关联，两者分开存储。每次新会话开始时，只加载长期记忆里的偏好，不加载历史对话内容。这样既有个性化，又不会让上下文无限膨胀。
4. FDE 视角：从买工具到真落地的完整流程
4.1 FDE 的五个阶段
FDE 不是一个人，是一种工作方式。我把它拆成五个阶段，每个阶段有明确的输入输出。
阶段一：业务测绘。花一周时间，跟业务部门的人聊，搞清楚他们每天在做什么、卡在哪里、哪些环节最耗时。输出是一张业务流程图，标注出"高耗时、高重复、高错误率"的三个环节。
阶段二：场景选型。从三个环节里选一个最适合 Agent 介入的。选择标准是：规则相对清晰、数据可获取、错误成本可控。不要一上来就选最难的，先做一个能跑通的。
阶段三：Agent 设计。根据选定的场景，设计 Agent 的知识架构（AKA 四层）、工具接口、权限边界。输出是一份 Agent 设计文档，包括 L1 提示词、L2 知识源、L3 工具清单、L4 记忆策略。
阶段四：原型验证。用 Codex 或 WorkBuddy 搭一个最小可用原型，找三到五个真实用户试用两周。收集反馈，迭代设计。
阶段五：规模推广。原型跑通后，整理成标准模板，推广到其他类似场景。同时建立反馈闭环，持续优化。
4.2 业务测绘怎么做才不流于形式
业务测绘最容易变成走过场。我的做法是跟着人干活，不是坐在会议室问。你跟着一个客服坐半天，看他一共处理了多少工单、每个工单花了多久、卡在哪一步、查了几次资料，这比问十遍"你觉得哪里最麻烦"都有用。
测绘的时候重点记录三类信息：操作步骤、查询来源、决策依据。操作步骤是 Agent 要替代的，查询来源是 L2 和 L3 要覆盖的，决策依据是 L1 要固化的。
4.3 场景选型的打分表
选场景不能凭感觉，我用一个简单的打分表。每个候选场景按五个维度打分，每项 1 到 5 分，总分最高的先做。
| 维度 | 说明 | 权重 |
|---|---|---|
| 规则清晰度 | 业务规则是否明确、可文档化 | 25% |
| 数据可得性 | 所需数据是否能通过接口获取 | 25% |
| 错误容忍度 | 出错后是否容易纠正、成本是否可控 | 20% |
| 使用频率 | 这个场景每天被触发的次数 | 15% |
| 用户接受度 | 相关同事是否愿意尝试新工具 | 15% |
我一般会选总分 3.5 以上的场景先做。低于 3 分的，要么规则太模糊，要么数据拿不到，硬做会翻车。
4.4 Agent 设计文档的模板
设计文档不需要很长，但必须包含以下部分。我把它做成一个模板，你可以直接抄。
一、场景描述 - 业务背景 - 当前痛点 - 期望效果 二、AKA 四层设计 - L1 常驻规则（完整提示词） - L2 知识源（文档清单 + 切块策略 + 元数据字段） - L3 工具清单（接口名 + 参数 + 权限 + 审计要求） - L4 记忆策略（短期/长期 + 存储位置 + 清理规则） 三、权限与合规 - 数据访问范围 - 操作白名单 - 审计日志字段 四、验证方案 - 试用用户名单 - 试用周期 - 成功指标（准确率、耗时、满意度） 五、迭代计划 - 反馈收集方式 - 迭代周期 - 负责人这份文档写清楚，后面搭原型就是照着做，不会跑偏。
5. 实操：用 Codex 和 WorkBuddy 搭一个业务 Agent
5.1 环境准备与基础配置
先说环境。Codex 的安装，官方文档写得很清楚，我补充几个实际会遇到的点。
安装完成后，第一件事是配置工作目录。我建议给每个业务场景单独建一个目录，目录结构长这样：
business-agent/ ├── config/ │ ├── l1-prompt.md # L1 常驻提示词 │ └── tools.json # L3 工具白名单 ├── knowledge/ │ ├── docs/ # L2 原始文档 │ └── index/ # L2 向量索引 ├── tools/ │ ├── query_order.sh # 业务查询脚本 │ └── check_stock.sh └── logs/ └── audit.log # 审计日志这个结构的好处是，Agent 的活动范围被限制在tools/目录，知识来源被限制在knowledge/目录，配置和日志分开，方便管理。
WorkBuddy 这边，主要是配置工作台的任务流。一个典型的任务流是：接收用户输入 → 路由到对应 Agent → Agent 调用工具 → 汇总结果 → 返回用户。WorkBuddy 的可视化编排能把这个流程画出来，每个节点可以绑定不同的 Agent 和工具。
5.2 L1 提示词的完整写法
L1 提示词我一般写成三段式：角色定义 + 核心规则 + 输出格式。
角色定义要具体，不要写"你是一个助手"，要写"你是 XX 公司的订单处理助手，服务对象是客服团队"。
核心规则就是前面说的条目式，每条一句话。
输出格式要明确，比如"涉及金额的回答，必须用表格呈现，包含订单号、金额、状态三列"。
一个完整的 L1 示例：
你是 XX 公司的订单处理助手，服务对象是客服团队。 核心规则： 1. 涉及订单状态、金额、库存的回答，必须调用 tools/ 目录下的脚本查询，不得凭记忆回答。 2. 涉及退款、改地址、取消订单的操作，必须提示客服确认，不得自动执行。 3. 输出内容不得包含数据库字段名、内部系统名称、员工真实姓名。 4. 无法确定的问题，明确说"需要查询后回复"，不得编造。 5. 每次回答末尾，标注信息来源（工具查询/知识库/规则推断）。 输出格式： - 涉及金额用表格，列：订单号、金额、状态 - 涉及流程用有序列表 - 涉及不确定信息，用"待确认"标注这个提示词大概 300 字，覆盖了角色、规则、格式三块，实测下来 Agent 的行为稳定很多。
5.3 L2 知识库的构建流程
L2 的构建分四步：收集、清洗、切块、索引。
收集就是把相关文档找齐，包括产品文档、FAQ、历史工单、培训材料。清洗是去掉过期的、重复的、格式混乱的。切块是按语义切，一个完整条目一块。索引是把块向量化，存进向量库。
切块这一步我重点说一下。以 FAQ 为例，一个问答对就是一个块，不要把一个问题的多个答案拆开。以工单为例，一个工单的"问题描述 + 解决方案"是一个块，中间的沟通记录可以去掉。以产品文档为例，一个功能点是一个块，包含功能说明、参数、示例。
每个块要带元数据，我一般用这几个字段：source（来源）、updated_at（更新时间）、department（适用部门）、confidence（置信度，1 到 5）。
5.4 L3 工具脚本的写法
L3 工具脚本我一般用 shell 或 Python 写，放在tools/目录下。每个脚本做一件事，参数明确，输出结构化。
一个查询订单的脚本示例：
#!/bin/bash # query_order.sh # 用法: ./query_order.sh <order_id> # 输出: JSON 格式的订单摘要 ORDER_ID=$1 if [ -z "$ORDER_ID" ]; then echo '{"error": "order_id is required"}' exit 1 fi # 调用内部接口，返回脱敏后的订单摘要 curl -s "http://internal-api/order/summary?id=${ORDER_ID}" \ | jq '{order_id, status, amount, created_at}' # 记录审计日志 echo "$(date -Iseconds) query_order ${ORDER_ID}" >> ../logs/audit.log这个脚本有三个关键点：参数校验、输出脱敏、审计日志。参数校验防止空调用，输出脱敏只返回必要字段，审计日志记录每次调用。
在 L1 提示词里，要明确告诉 Agent 只能调用tools/目录下的脚本，并且要说明每个脚本的用途和参数。这样 Agent 才知道什么时候用哪个工具。
5.5 WorkBuddy 任务流的编排
WorkBuddy 这边，我一般把任务流设计成"路由 + 执行 + 汇总"三段。
路由段根据用户输入判断意图，分发给不同的 Agent。比如订单问题给订单 Agent，技术问题给技术 Agent。路由可以用规则，也可以用一个小模型做分类。
执行段就是各个 Agent 干活，调用各自的工具，生成各自的输出。
汇总段把多个 Agent 的输出合并，去重、排序、格式化，返回给用户。
WorkBuddy 的可视化编排能把这个流程画出来，每个节点可以配置超时、重试、降级策略。我一般给每个节点配 30 秒超时，失败重试一次，再失败就返回"暂时无法处理，请稍后重试"。
5.6 权限与审计的落地细节
权限这块，我的做法是三层隔离：网络隔离、接口隔离、数据隔离。
网络隔离是 Agent 只能访问内网特定网段，不能访问外网。接口隔离是 Agent 只能调用白名单里的接口，白名单在tools.json里配置。数据隔离是接口返回的数据已经脱敏，Agent 拿不到原始敏感数据。
审计日志我记录这几个字段：timestamp、user_id、agent_id、tool_name、parameters、result_status、duration_ms。这些字段足够追溯任何一次调用。
日志我一般保留 90 天，每天归档一次。归档的时候做一次聚合分析，看看哪些工具调用最频繁、哪些失败率最高，作为优化依据。
6. 常见问题与排查技巧实录
6.1 Agent 答非所问怎么办
这是最高频的问题。排查思路是从 L1 到 L4 逐层检查。
先看 L1 提示词是不是太模糊。如果规则写得含糊，Agent 就会自由发挥。把规则改具体，加上"必须""不得"这类强约束词。
再看 L2 检索是不是没召回正确内容。把用户的问题和检索结果对比，如果检索出来的块跟问题不相关，说明切块或索引有问题。调整切块粒度，或者加元数据过滤。
再看 L3 工具是不是没调用。如果 Agent 应该查数据但没查，说明 L1 里没有明确要求，或者工具描述不清楚。在 L1 里加"涉及 X 必须调用 Y 工具"。
最后看 L4 记忆是不是污染了上下文。如果之前的对话有错误信息被记住了，会影响后续回答。清理会话记忆，重新开始。
6.2 工具调用失败怎么排查
工具调用失败一般有三类原因：参数错误、权限不足、接口超时。
参数错误看审计日志里的parameters字段，对比脚本要求的参数格式。常见问题是 Agent 传了多余参数或漏了必填参数。解决办法是在 L1 里明确每个工具的参数格式。
权限不足看接口返回的错误码。如果是 403，说明白名单没配好，或者接口的权限策略变了。检查tools.json和接口侧的配置。
接口超时看duration_ms字段。如果经常超过 30 秒，说明接口性能有问题，或者数据量太大。优化接口查询，或者加缓存。
6.3 输出格式不稳定怎么治
Agent 输出格式飘忽，是因为 L1 里的格式要求不够具体。我的经验是给例子，不要只描述。
比如你要表格，不要写"用表格呈现"，要写"用 Markdown 表格呈现，表头为：订单号 | 金额 | 状态，每行一个订单"。
再比如你要 JSON，不要写"输出 JSON"，要写"输出 JSON，字段为 order_id、status、amount，示例：{"order_id": "123", "status": "paid", "amount": 99.00}"。
给了例子，Agent 的格式稳定性会大幅提升。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决办法 |
|---|---|---|---|
| 答非所问 | L1 模糊 / L2 召回错 | 对比问题与检索结果 | 改具体规则 / 调切块 |
| 不调用工具 | L1 未强制 / 工具描述不清 | 看审计日志有无调用 | L1 加强制规则 |
| 工具调用失败 | 参数错 / 权限不足 / 超时 | 看审计日志详情 | 明确参数 / 查白名单 / 优化接口 |
| 格式不稳定 | L1 格式要求模糊 | 看输出与要求差异 | 给具体例子 |
| 越用越笨 | 无反馈闭环 | 看错误是否重复 | 建反馈机制 |
| 上下文爆炸 | L4 记忆无清理 | 看会话长度 | 分级记忆 + 定期清理 |
6.5 几个我踩过的坑
坑一：L1 写太长。我一开始把 L1 写到 3000 字，结果 Agent 注意力分散，关键规则反而被忽略。后来压到 1000 字以内，效果明显变好。
坑二：L2 切块太碎。我按 200 字切块，结果检索出来的都是半截信息。后来改成按语义切，一个完整条目一块，召回质量提升很多。
坑三：L3 工具太多。我一开始给 Agent 配了 20 多个工具，结果它经常选错。后来收敛到 5 个核心工具，准确率上来了。工具不是越多越好，够用就行。
坑四：审计日志没看。我上线后一个月没看日志，后来一看发现有个工具调用失败率 40%，白白浪费了一个月。现在我每周看一次日志，及时发现问题。
坑五：反馈没人管。用户标记了错误，但没人整理，结果同一个错误反复出现。后来我指定了一个人每周整理反馈，把高频错误转成 L1 规则或 L2 知识，Agent 才真正在进化。
7. 从单点落地到规模推广
7.1 单点跑通后的标准化
一个场景跑通后，不要急着做下一个，先把第一个标准化。标准化的意思是：把 L1 提示词、L2 知识源、L3 工具、L4 记忆策略，整理成可复用的模板。
模板要包含：场景描述、AKA 四层配置、权限设计、验证方案、迭代计划。下次做类似场景，直接改模板，不用从零开始。
我一般会把模板放在内部 Wiki 上，团队共享。每做一个新场景，就更新一次模板，把新踩的坑、新总结的经验加进去。
7.2 推广时的组织配套
推广不是技术问题，是组织问题。我的经验是找对种子用户，让他们先用起来，再带动其他人。
种子用户的选择标准是：业务熟练、愿意尝试、有影响力。业务熟练保证他们能判断 Agent 输出对不对，愿意尝试保证他们不会一遇到问题就放弃，有影响力保证他们能带动周围同事。
种子用户用起来后，组织一次内部分享，让他们讲自己的使用体验。真实用户的分享，比技术团队的培训有效十倍。
7.3 持续迭代的机制
Agent 上线不是终点，是起点。我一般建立三个机制：周度日志分析、月度反馈整理、季度架构评审。
周度日志分析看工具调用成功率、响应时间、高频问题。月度反馈整理把用户标记的错误转成知识条目或规则修正。季度架构评审看 AKA 四层是否需要调整，比如 L2 知识源是否需要扩充，L3 工具是否需要增减。
这三个机制跑起来，Agent 就会持续进化，而不是上线即巅峰。
7.4 一个真实的推广案例
我做过一个客服场景的 Agent，从单点跑通到全团队推广，用了三个月。
第一个月，选了一个客服小组做试点，五个人，每天处理 200 个工单。Agent 上线后，平均处理时间从 8 分钟降到 5 分钟，准确率 85%。
第二个月，根据试点反馈，优化了 L1 规则和 L2 知识，准确率提到 92%。然后推广到三个小组，二十个人。
第三个月，整理成标准模板，推广到全部客服团队，八十个人。同时建立了周度日志分析和月度反馈整理机制。
现在这个 Agent 每天处理 3000 多个工单，准确率稳定在 90% 以上，客服团队的平均处理时间降了 40%。这个结果不是靠工具本身，是靠 FDE 的思路和 AKA 的方法，把工具真正嵌进了业务里。
8. 一些个人体会
做 AI 落地这件事，我最大的体会是：工具只是起点，定制才是价值。企业买 Codex、买 WorkBuddy，买的是能力，但能力要变成生产力，中间隔着业务理解、知识架构、权限设计、反馈闭环这一整套工程。
FDE 的思路是让你站在业务里看技术，AKA 的方法是让你把知识拆成 Agent 能吃的粒度。两者结合，才能让通用 Agent 变成企业自己的 Agent。
如果你正在做类似的事，我的建议是：先选一个场景，把它做透，再推广。不要贪多，不要一上来就搞大平台。一个场景跑通，比十个场景半途而废有价值得多。
最后分享一个小技巧：每次 Agent 答错，不要只改提示词，要问自己"这个错误暴露了哪一层的缺失"。是 L1 规则没写清楚，还是 L2 知识没覆盖，还是 L3 工具没调用，还是 L4 记忆污染了。找到那一层，改那一层，比盲目调提示词有效得多。
