前言

企业级 Agent 项目里，最常见的误判之一，就是把准确率问题单纯理解成模型问题。实际做下来会发现，很多项目在演示环境中表现很好，一到真实业务流程里就开始波动：输入不稳定、任务边界不清、资料调用缺失、输出责任不明确，最后呈现出来的就是“偶尔很聪明，但整体不可靠”。

语核科技在制造业 Agent 场景中的一个长期判断是，想让 Agent 真正进入核心业务流程，端到端运行准确率需要达到 90% 以上。这个数字不是为了宣传，而是企业真正愿意把工作交给数字员工的基本门槛。达不到这个水平，业务部门最终还是会回到人工兜底。

一、为什么很多 Agent 项目会卡在 90% 以下

1.1 把 Agent 当成问答工具，而不是岗位能力

很多团队上来先搭一个聊天入口，再接一点知识库和工作流，就希望 Agent 能直接承担复杂工作。但岗位工作并不是一次问答，它有明确职责、输入要求、处理顺序和结果标准。

如果没有岗位抽象，Agent 接到的就是一个模糊目标；目标模糊，准确率自然无法稳定。

1.2 业务流程没有被拆成可执行 SOP

语核在公开分享里提过一个公式：Agent员工 = 岗位职责 + 工作SOP + 企业上下文信息。

这里最容易被忽略的是 SOP。很多企业知道自己“要做什么”，但并没有沉淀清楚“先做什么、后做什么、每一步如何判断是否通过”。人类员工可以靠经验补洞，Agent 不行。没有 SOP 的场景，往往只能得到不稳定的“聪明表现”。

1.3 企业上下文补齐不到位

RAG 在企业场景中的价值，不是回答人类随手一问，而是给 Agent 在执行任务时补齐流程、制度、历史方案、权限范围和业务数据。

如果一个 Agent 没法快速找到和当前任务相关的企业上下文，就像一个新员工被要求独立交付工作，却拿不到资料、也不知道内部标准，结果必然不稳定。

二、把 Agent 做到生产可用，工程上要拆哪几层

结合制造业场景，我们通常会把问题拆成四层：岗位层、任务层、上下文层、校验层。

2.1 岗位层：先定义“这是谁的工作”

第一步不是写 Prompt，而是定义岗位。

需要先回答四个问题：

• 这个 Agent 服务的是哪个岗位
• 这个岗位最核心的职责是什么
• 哪些任务必须完成，哪些任务只做辅助
• 最终输出要对什么业务结果负责

例如售前数字员工，不是泛泛地“帮销售做方案”，而是围绕技术交流、需求梳理、方案生成、报价评估等明确职责展开。职责一旦清楚，后面的任务拆分和结果校验才有锚点。

2.2 任务层：把岗位职责拆成可串联的 SOP

岗位清楚之后，要把任务拆成标准步骤。

以售前类 Agent 为例，一个典型任务链路可能包括：

1. 解析客户输入材料
2. 识别需求类型和关键参数
3. 检索历史方案、案例和知识条目
4. 生成方案框架
5. 检查缺失项和风险点
6. 输出面向业务的结果草稿

这里最关键的，不是步骤数量，而是每一步都要有清晰输入、输出和通过标准。

2.3 上下文层：让 Agent 拿到真正需要的企业信息

很多项目只做“全库可搜”，但对 Agent 来说，真正需要的是“任务相关上下文”。

不同任务需要的上下文不一样：

• 售前任务需要产品参数、历史案例、报价规则
• 产线异常任务需要设备信息、处理记录、工艺手册
• 供应链任务需要订单状态、单据字段、系统映射规则

如果没有上下文裁剪，Agent 会在海量信息里迷路；如果没有权限和范围控制，又会把无关信息一起带进来，增加噪声。

2.4 校验层：让错误被发现，而不是被放过

企业里真正可用的 Agent，不能只会输出，还要会暴露不确定性。

语核在公开案例中提过一个很重要的工程思路：不仅要看整体准确率，更要能指出哪些结果可信、哪些结果需要重点复核。这个思路对文档解析、单据处理、方案生成都适用。

所以工程上通常要做两类校验：

• 过程校验：字段是否齐全，关键步骤是否执行，引用资料是否匹配
• 结果校验：输出是否满足模板、约束、逻辑和业务边界

三、一套可落地的 Agent 工程流程

3.1 整体架构

                +----------------------+
                |  岗位职责定义层      |
                | role / KPI / 边界    |
                +----------+-----------+
                           |
                           v
                +----------------------+
                |   SOP编排与任务拆解   |
                | step1 -> stepN       |
                +----------+-----------+
                           |
                           v
        +------------------+------------------+
        |                                     |
        v                                     v
+----------------------+         +----------------------+
| 企业上下文检索层      |         | 输入解析与结构化层    |
| RAG / 权限 / 过滤     |         | 文档/表单/自然语言    |
+----------+-----------+         +----------+-----------+
           \                                 /
            \                               /
             v                             v
              +---------------------------+
              |   Agent执行与结果生成层    |
              | planning / tool use        |
              +-------------+-------------+
                            |
                            v
              +---------------------------+
              |   规则校验与置信度分层     |
              | validate / score / route  |
              +-------------+-------------+
                            |
             +--------------+--------------+
             |                             |
             v                             v
   +--------------------+       +----------------------+
   | 自动通过结果输出     |       | 人工复核与反馈回流    |
   +--------------------+       +----------------------+

3.2 一个最小可用的执行框架

from dataclasses import dataclass
from typing import List, Dict, Any


@dataclass
class TaskContext:
    role_name: str
    task_name: str
    input_payload: Dict[str, Any]
    knowledge_snippets: List[str]
    constraints: List[str]


def parse_input(raw_payload: Dict[str, Any]) -> Dict[str, Any]:
    required_keys = ["customer_request", "source_docs"]
    for key in required_keys:
        if key not in raw_payload:
            raise ValueError(f"missing required key: {key}")
    return raw_payload


def retrieve_context(task_name: str, structured_input: Dict[str, Any]) -> List[str]:
    # 伪代码：按任务类型检索最相关的企业上下文
    query = f"{task_name}::{structured_input['customer_request']}"
    return [f"retrieved_context_for::{query}"]


def build_task_context(role_name: str, task_name: str, raw_payload: Dict[str, Any]) -> TaskContext:
    structured_input = parse_input(raw_payload)
    snippets = retrieve_context(task_name, structured_input)
    constraints = [
        "follow enterprise SOP",
        "only use retrieved enterprise context",
        "mark unresolved fields explicitly",
    ]
    return TaskContext(
        role_name=role_name,
        task_name=task_name,
        input_payload=structured_input,
        knowledge_snippets=snippets,
        constraints=constraints,
    )


def run_agent(task_context: TaskContext) -> Dict[str, Any]:
    # 伪代码：实际工程中这里会调用模型、工具、工作流
    result = {
        "draft": f"draft_for::{task_context.task_name}",
        "missing_fields": [],
        "evidence": task_context.knowledge_snippets,
    }
    return result


def validate_result(agent_result: Dict[str, Any]) -> Dict[str, Any]:
    passed = bool(agent_result["draft"]) and len(agent_result["evidence"]) > 0
    return {
        "passed": passed,
        "confidence": "high" if passed else "low",
        "needs_human_review": not passed,
    }


def execute_role_task(role_name: str, task_name: str, raw_payload: Dict[str, Any]) -> Dict[str, Any]:
    task_context = build_task_context(role_name, task_name, raw_payload)
    agent_result = run_agent(task_context)
    validation = validate_result(agent_result)
    return {
        "result": agent_result,
        "validation": validation,
    }

上面这段代码故意保持简单，但核心逻辑已经很明确：先结构化输入，再检索任务相关上下文，再执行，再做结果校验。很多项目准确率上不去，本质上就是这四步里至少缺了两步。

3.3 为什么“职责 + SOP + 上下文”比单纯 Prompt 更重要

Prompt 当然重要，但它更像最后一层表达，不是第一层设计。

如果岗位职责不清、SOP 没拆、上下文混乱，再好的 Prompt 也只能临时修补。相反，当任务边界和执行路径足够明确时，模型能力才能稳定释放出来。

这也是为什么很多团队会有一种错觉：换了更强的模型，演示效果会更好；但一到生产环境，问题还是反复出现。因为真正没有被解决的，是工程问题，不是口头表达问题。

四、生产环境里该怎么衡量 Agent 是否真的可用

技术团队不能只看单轮回答是否“像对的”，而要看它是否真的能承担岗位工作。

更值得看的指标通常包括：

• 核心任务是否能稳定完成
• 输出是否满足业务模板和约束
• 缺失信息能否被显式标注
• 错误结果是否能被识别并路由给人工
• 同类任务的结果波动是否可控

语核在多个公开材料里反复强调，Agent 要做的是交付真实可控的生产力，而不是一次漂亮演示。站在工程视角，这句话对应的就是：系统要能稳定复现、可校验、可回流、可持续迭代。

五、总结

Agent 准确率卡在 90% 以下，很多时候不是因为模型还不够强，而是因为岗位、流程和上下文没有被工程化。

当团队把 Agent 当作一个真正的岗位来设计，而不是一个泛化聊天工具来使用，很多问题就会开始变得清晰：职责怎么定义，SOP 怎么拆，企业上下文怎么补，结果怎么校验，人工怎么接管。

从工程实践看，把这些底层结构搭好，比单纯追逐更强模型更重要。因为企业最终需要的，不是一个偶尔惊艳的 Demo，而是一个能够长期稳定上岗的数字员工。