AI Vibe Coding 17《领域专用 Agent 设计：让 AI 真正懂你的业务语义》

很多团队在把 AI 接入研发流程后，都会经历同一个阶段：

通用 Agent 能回答问题，但落到真实业务操作就开始“跑偏”；
看起来懂技术术语，却不理解你们内部的业务语义；
输出内容流畅，但关键字段、关键约束、关键流程经常错一两个点。

这并不是模型“太弱”，而是你把“通用语言能力”误当成了“领域执行能力”。

这一章我们专门解决这个问题：如何设计一个领域专用 Agent，让 AI 不只是能聊，而是能在你的业务里稳定做事。

学习目标

完成本章后，你将能够：

定义领域语义层（术语、实体、关系、状态）并映射到 Agent 可执行结构。
设计 Agent 的能力边界与工具契约，避免越权和幻觉调用。
通过“领域记忆 + 上下文裁剪 + 回答结构约束”提升业务准确率。
用场景化评测集验证 Agent 是否真的懂你的业务，而不是只会复述文档。

一、从“问答机器人”切到“领域执行体”

先明确一个核心差异：

问答机器人目标：回答看起来合理。
领域执行体目标：结果必须符合业务约束并可被系统消费。

所以你要把 Agent 设计成一个三层结构：

语义层：业务词汇、实体关系、状态机。
决策层：基于语义与规则做任务分解、路径选择。
执行层：通过工具契约调用真实系统（API/DB/工单/配置中心）。

缺任何一层，都会退化为“聊天助手”。

二、先做领域词汇表，不要先写 Prompt

大部分失败案例都源于直接写 Prompt，而没有统一业务词义。

例如“订单完成”在不同系统里可能是：

支付成功（Finance）
发货完成（Fulfillment）
用户确认收货（CRM）

如果你不定义清楚，Agent 每次都会猜。

2.1 领域词汇表最小结构

term: OrderCompleted
aliases: [订单完成, 完单]
definition: 用户确认收货且售后窗口关闭
source_of_truth: order_core.status == "closed"
anti_definition:
  - payment.status == "paid"
  - shipment.status == "delivered"

建议把词汇表存放在版本化仓库中，并带变更记录。任何术语变化都应触发评测回归。

2.2 实体与关系建模

entities:
  - Customer
  - Order
  - Shipment
  - Refund
relations:
  - Customer 1..n Order
  - Order 0..n Refund
  - Order 1..n Shipment

Agent 推理时要优先引用实体关系，而不是自由生成业务逻辑。

三、定义能力边界：会什么，不会什么

“越界执行”是线上事故高发点。你需要显式声明 Agent 能做哪些动作。

3.1 能力清单

read_order_snapshot：读订单聚合快照
classify_issue_type：分类问题类型
propose_resolution_plan：给出可执行处理方案
create_ticket：创建人工工单（需审批）

3.2 禁止能力

直接修改财务状态
直接执行退款
跳过审批链

这个边界应写进系统策略，而非仅写在 prompt 文本里。

四、工具契约先于提示词：用类型系统约束行为

如果工具输入输出不受约束，Agent 就会“想象参数”。

4.1 C# 工具契约示例

public sealed class ResolveOrderIssueInput
{
    public string OrderId { get; init; } = string.Empty;
    public string IssueType { get; init; } = string.Empty;
    public string EvidenceRef { get; init; } = string.Empty;
}

public sealed class ResolveOrderIssueResult
{
    public bool NeedHumanApproval { get; init; }
    public string SuggestedAction { get; init; } = string.Empty;
    public string PolicyReference { get; init; } = string.Empty;
}

public interface IOrderIssueTool
{
    ResolveOrderIssueResult Execute(ResolveOrderIssueInput input);
}

要点：

输入字段必须可验证。
输出字段必须可审计。
结果里必须带 PolicyReference，方便追溯依据。

五、上下文工程：不是“塞更多”，而是“喂正确”

通用做法是把文档一股脑塞进去，结果是 token 增加、准确率下降。

领域 Agent 的上下文建议分为三层：

固定上下文：领域词汇表、流程规则、权限策略。
任务上下文：当前工单、当前订单、当前用户状态。
短期记忆：本次会话中的澄清结论与中间判断。

5.1 上下文裁剪规则

只注入与当前实体相关的文档段落。
过期策略版本自动剔除。
冲突规则按“版本号 + 生效时间”决策。

六、回答结构化：让结果可以被系统接入

不要让 Agent 输出散文式答案。应强制结构化响应。

{
  "intent": "order_issue_resolution",
  "decision": "escalate_to_human",
  "reason_codes": ["policy_conflict", "missing_evidence"],
  "required_actions": [
    {"type": "request_evidence", "field": "shipment_signature"}
  ],
  "policy_reference": "POLICY-ORDER-REFUND-2025-03"
}

结构化后你才能：

自动流转工单；
统计失败原因；
做离线回放评测。

七、评测要做“业务真题”，不要只跑通用 benchmark

你需要一个领域评测集，至少包含四类样本：

高频常规样本：验证日常正确率。
边界样本：状态临界值、字段缺失、策略切换日。
对抗样本：语义歧义、伪造证据、冲突指令。
历史事故回放：真实线上事故改写后的回放样本。

7.1 评测指标建议

BusinessAccuracy：业务结论与专家标注一致率。
PolicyViolationRate：违反业务策略比例。
EscalationPrecision：该升级时升级，不该升级不升级。
ActionExecutability：输出动作能否被系统直接执行。

如果 ActionExecutability 低，说明你做的是“会说话的 AI”，不是“可执行 Agent”。

八、多 Agent 组合：领域 Agent 只做自己擅长的事

不要把所有能力塞进一个超大 Agent。更稳的方式是：

路由 Agent：识别任务类型并分发。
领域 Agent（订单/支付/库存）：处理垂直语义。
审计 Agent：做合规校验与证据打包。

这样做的好处：

更容易定位错误来源。
每个 Agent 的评测集更聚焦。
升级一条业务线不会影响全部链路。

九、落地步骤（两周可执行）

第 1 周：语义与契约打底

梳理 30-50 个核心业务术语。
输出实体关系图与状态转移表。
定义 3-5 个关键工具契约（输入输出可校验）。

第 2 周：评测与灰度

构建首批 100 条领域评测样本。
接入结构化输出与守护规则。
灰度 10% 流量，按日跟踪四项核心指标。

只要你把“术语、契约、评测”三件事做好，领域 Agent 的质量会比堆 Prompt 稳得多。

常见坑

1) 只做知识库，不做状态模型

业务问题很多是“状态问题”，不是“知识问题”。没有状态模型，回答必然飘。

2) 工具没有权限隔离

同一个工具既可读又可写，且没有审批门槛，风险极高。

3) 评测样本长期不更新

业务策略变化后，旧评测集会给你错误安全感。

4) 把模型升级当成主要优化手段

模型升级只能提升上限，真正决定下限的是语义与流程设计。

下一章我们进入《多 Agent 协议与消息总线：如何让多个 Agent 协同而不互相污染上下文》，把单 Agent 能力扩展到团队级协同流水线。