AI Agent 掌握专业领域：四层方法

开源检索文档指出，RAG 主要解决大模型上下文有限和训练知识静态这 2 个问题，但它本身不负责定义业务流程，也不会自动获得操作权限。检索与 RAG 的官方文档说明 因此，只做 RAG 不等于让 AI Agent 掌握专业领域。

你应该把领域能力拆成四层：Knowledge Base 回答“知道什么”，Agent Skills 定义“怎么做”，工具调用负责“实际操作”，评估集验证“是否可靠”。只写 Skill 会缺少可追溯知识，只接知识库则容易停留在问答，四层必须一起设计。

这篇文章适合正在开发专业领域 Agent 的 AI 工程师、需要沉淀内部 SOP 和动态知识的平台团队，以及准备把领域 Agent 部署到持续运行环境的项目负责人。

先划清四层职责：知识、流程、工具和评估不能混在一起

专业 Agent 的第一个问题不是选择哪种模型，而是判断一条信息应该放在哪里。你可以先用下面这张表建立边界：

这里的四层不是产品功能清单，而是责任分配。Knowledge Base 可以被多个 Skill 复用，Skill 也可以调用多个工具；但是知识来源、流程规则和执行权限必须能够单独修改，否则一次资料更新就可能意外改变整个 Agent 的行为。

两者分别负责事实与流程

Knowledge Base 是可检索、可引用、可更新的事实层。它应该保留文档来源、版本、负责人、适用范围和更新时间，让 Agent 的回答能够回到原始证据，而不是把模型自身训练知识当成可审计数据源。

Agent Skills 则是流程层。它更像一份供 Agent 执行的专业 SOP：先判断输入是否完整，再调用指定知识检索，满足条件后执行某个工具，最后按照固定格式输出结果。Skill 可以引用知识库中的内容，但不应把整个知识库复制进去。

例如，在运维场景中，“某版本服务的默认端口是多少”属于 Knowledge Base；“发现服务异常后，先检查状态，再读取日志，确认影响范围后才允许重启”属于 Agent Skills。前者会随版本变化，后者通常保持相对稳定。

按证据链建设 Knowledge Base：先解决知道什么

1．为每份资料保留可追溯元数据

不要把多个部门的 PDF、聊天记录和网页直接混成一个向量库。至少为每份资料保留以下字段：

• 来源地址或文件路径；
• 文档所有者与适用团队；
• 生效版本、发布日期和失效日期；
• 允许访问的角色或项目；
• 内容类型，例如规范、案例、操作手册或历史记录；
• 是否属于动态事实，是否需要优先从实时系统查询。

检索结果至少要返回标题、来源、版本和相关片段。对高风险问题，还应要求 Agent 在答案中给出证据位置；如果没有命中可信资料，就明确回答“当前知识库没有足够依据”，而不是使用模型记忆补齐。

2．把动态事实和稳定知识分开

库存、服务状态、价格、权限、发布版本和排班信息，不适合长期固化在 Skill 或静态文档里。它们应通过实时 API、数据库查询或受控工具获取，并在返回中携带查询时间和数据范围。

相反，故障分级标准、代码评审规则、设计交付格式和审批条件，通常更适合写入 Skill。这样更新一个版本号时，不需要重新改写整套执行流程。

经验提醒：如果某条规则既被写进知识库，又被复制到 Skill、系统提示词和工具描述中，后续最容易出现“检索结果说 A，Skill 要求 B”的冲突。保留一个权威来源，其余位置只引用它。

3．用检索质量检查替代“感觉答得不错”

至少检查四类情况：正确资料能否被召回、相似资料是否会混淆、权限过滤后是否仍然返回正确内容、过期文档是否会被错误优先使用。

你可以参考 Knowledge Base 的检索架构说明，把知识入口、切分、索引、检索、重排和引用展示分开记录。对于企业内部资料，还要把权限过滤放在检索链路中，而不是只在最终回答阶段隐藏内容。

按 SOP 封装 Agent Skills：再解决怎么做

4．一个 Skill 只负责一类稳定任务

Skill 不应该写成“你是某领域专家，请自由处理所有请求”。可执行的 Skill 应包含：

1. 任务适用范围；
2. 必需输入和缺失输入的处理方式；
3. 每一步的动作与判断条件；
4. 允许调用的知识源和工具；
5. 成功、失败、超时和人工介入的分支；
6. 最终输出格式；
7. 完成前必须执行的检查项。

比如“发布服务”这个 Skill，可以规定先检查目标环境、版本、变更单和回滚点；如果缺少审批编号，就停止执行并请求补充，而不是继续调用发布工具。

Agent Skills 适合保存流程，不适合保存所有背景知识。Skill 越长，越容易与 Knowledge Base 分叉，也越难判断一次知识更新是否影响执行行为。

5．为 Skill 设计拒绝条件和回退路径

专业能力不只体现在“能做什么”，也体现在“什么时候不能做”。以下情况应写成明确规则：

• 资料版本不匹配时，停止并要求确认；
• 工具返回字段不完整时，不得猜测成功；
• 用户权限不足时，转为只读查询；
• 操作影响生产环境时，进入人工审批；
• 连续重试超过预设限制时，输出故障上下文并结束当前动作。

这一步可以显著降低“Agent 看起来完成了任务，但实际没有完成”的问题。对平台团队来说，失败后的可恢复性往往比一次成功演示更重要。

为工具调用划定权限：能操作不代表应该操作

工具调用至少要区分只读、写入、执行和审批四种动作。只读工具可以查询状态和日志；写入工具可能修改配置；执行工具可能触发部署、重启或批量变更；审批工具则应保留给具备明确责任的人或系统。

Model Context Protocol 的工具规范强调，工具代表任意代码执行能力，应用应提供用户理解和拒绝调用的机会。对于跨系统调用，还应参考 MCP 授权规范，做好令牌存储、权限范围、过期、轮换和目标资源绑定。

工具返回不要只给一句“执行成功”。建议统一成结构化结果：

{
  "status": "success",
  "operation": "restart_service",
  "target": "staging",
  "changed": true,
  "next_action": "check_health",
  "evidence": "deployment-log-id"
}

失败时也要返回错误类型、是否发生部分变更、是否允许重试和推荐的下一步。否则 Agent 无法区分网络超时、权限不足、参数错误和目标服务本身故障。

用评估集验证：如何确认 AI Agent 真的掌握专业知识

6．把评估集做成四类样本

不要只准备“标准问题—标准答案”。一个能用于上线决策的领域评估集，至少应包含：

• 知识问答：答案是否引用正确版本和原始证据；
• 流程执行：是否按 Skill 顺序调用工具并完成检查；
• 边界拒绝：权限不足、资料缺失或高风险请求是否正确拒绝；
• 过期与故障：旧知识、冲突资料、工具超时和错误返回是否被识别。

官方评估接口支持定义数据源、测试标准和多次运行结果，适合把同一批样本用于更新前后的固定基线比较。评估数据源与运行机制说明 你也可以把每次失败记录为新的回归样本，而不是只在上线前临时测试。

7．用指标定位问题，而不是只看总分

知识回答错误，通常要回查资料版本、检索召回和权限过滤；流程执行错误，通常要回查 Skill 分支和工具返回；误操作，则要回查授权范围、人工确认和状态恢复。

建议每次评估至少记录：

• 证据是否来自允许的资料；
• 是否选择了正确 Skill；
• 工具参数是否完整；
• 是否在不满足条件时停止；
• 输出是否符合格式；
• 失败后是否保留足够上下文。

模型版本、提示词或检索策略变化后，应重新运行同一评估集。模型输出可能随版本变化，即使输入和提示词没有改变，也不能只凭一次人工演示判断系统已经稳定。模型版本与评估建议

建立更新机制：知识变化先影响 Knowledge Base，再判断 Skill

专业 Agent 的维护责任必须明确到人，而不是写成“团队定期更新”。你需要为每类资料指定负责人、更新触发条件、复核人和冲突处理规则。

当新版本资料进入系统时，按下面顺序处理：

1. 标记旧资料是否失效；
2. 更新 Knowledge Base 的版本、来源和权限；
3. 运行受影响的知识问答样本；
4. 判断是否改变现有 Skill 的条件或输出；
5. 若流程受影响，再更新 Skill；
6. 更新工具参数或权限时，重新执行安全评估；
7. 通过固定评估集后，才逐步扩大部署范围。

如果两份资料冲突，不要让 Agent 自行“综合判断”。应根据文档优先级、发布日期、负责人确认或适用环境建立明确规则，并把冲突状态记录下来。

上线前执行领域 Agent 验收清单

• [ ] 每个知识片段都有来源、版本、更新时间和权限标记。
• [ ] 动态事实通过实时工具获取，没有被长期复制进 Skill。
• [ ] 每个 Skill 都写明输入、步骤、分支、输出和拒绝条件。
• [ ] 工具按只读、写入、执行和审批区分权限。
• [ ] 高风险动作必须经过人工确认，且能说明将要改变什么。
• [ ] 工具返回包含成功、失败、部分变更和下一步字段。
• [ ] 评估集覆盖知识问答、流程执行、拒答、过期信息和工具故障。
• [ ] 更新 Knowledge Base 后，能够定位受影响的 Skill 和评估样本。
• [ ] 凭据不写入提示词、日志或 Skill 文件。
• [ ] 运行环境具备隔离、日志、状态恢复和并发限制。
• [ ] 低风险内部辅助可以分阶段开放，外部自动操作设置更高审批门槛。
• [ ] 关键组件升级后，使用同一基线重新评估，而不是只做冒烟测试。

如果你的团队还没有明确的运行环境，可以先阅读 ZavCloud 帮助中心，把隔离环境、远程访问、凭据保存和日志留存列入部署方案；需要临时搭建 Mac 上的开发或测试节点时，也可以了解 Mac 云租用方案。

对于持续运行的专业 Agent，直接放在个人电脑上通常会遇到设备休眠、网络变化、权限混用和状态丢失；共享云主机又可能带来环境漂移、远程图形工具不稳定以及团队成员之间难以隔离的问题。若你只是需要临时验证 Knowledge Base、Agent Skills、工具调用和评估集这条链路，租用 ZavCloud 的 Mac 环境可以把测试节点、账号权限和运行时状态分开管理，先完成验收，再决定是否购买或长期建设自己的硬件。需要长期稳定重负载、物理接口或固定专用网络的团队，则应优先评估自购设备或专属基础设施，而不是把租赁当成永久替代方案。