前言

语核科技技术团队在制造业B2B场景中长期实践Agent落地，服务客户涵盖重工装备、半导体、航运等行业。我们发现了一个反复出现的工程困境：

一个Agent从Demo到生产可用，最大的鸿沟不是在模型层，而是在"岗位定义层"。Demo可以用宽泛的Prompt跑出看起来不错的结果；但生产环境里，客户的真实输入五花八门，Agent必须在没有人工兜底的情况下稳定输出——而这要求Agent的职责边界、执行路径和知识底座必须被清晰工程化。

语核科技将这个工程化过程提炼为一个核心公式：

Agent员工 = 岗位职责(Role) + 工作SOP(Process) + 企业上下文(Context)

本文详细拆解这三个工程阶段的具体实现路径。

---

一、为什么岗位定义是Agent准确率的瓶颈

1.1 生产环境与Demo的根本差异

在Demo阶段，工程师通常会精心设计输入，规避模型的边界。但生产环境里的真实输入是不可控的：

• 用户表达方式各异（口语化、残缺、带歧义）
• 同一类问题背后有完全不同的业务意图
• 输入中混杂着无关信息需要过滤

如果Agent的职责边界不清晰，它就会在"该回答"和"不该回答"之间随机漂移，导致准确率在生产环境中远低于测试集表现。

1.2 "模糊岗位"的典型症状

以制造业售前场景为例，一个典型的模糊岗位定义可能是：

# 错误示范 - 过于宽泛
system_prompt = """
你是一个售前助手，帮助用户回答任何售前相关问题。
"""

这个定义的问题在于：

• "售前相关问题"边界不明确
• 没有定义什么情况下需要检索知识库
• 没有定义输出格式和质量标准
• 没有处理超出职责范围的请求的逻辑

结果就是：Agent什么都回答，但什么都回答得不够准。

---

二、第一阶段：岗位职责工程化

2.1 职责边界拆解方法

职责边界的工程化，需要回答四个问题：

1. 输入是什么：Agent接收什么形式的请求（自由文本、结构化表单、文档上传）
2. 输出是什么：Agent输出什么格式的结果（方案文档、参数表、结构化JSON）
3. 边界在哪里：哪些请求在职责内，哪些需要转人工或拒绝
4. 成功标准是什么：什么样的输出算达标

以售前报价场景为例，经过工程化拆解后：

ROLE_DEFINITION = {
    "name": "售前报价Agent",
    "input_types": [
        "客户需求文件（PDF/Word）",
        "客户自然语言需求描述",
        "参数对比查询请求"
    ],
    "output_types": [
        "结构化需求要素提取表",
        "历史相似案例列表（含相似度评分）",
        "初步方案框架（含核心参数建议）",
        "报价范围参考"
    ],
    "out_of_scope": [
        "合同条款谈判建议",  # 转法务
        "最终报价确认",      # 转人工审批
        "客户资质评估"       # 转销售负责人
    ],
    "quality_threshold": 0.90  # 生产可用准确率门槛
}

2.2 职责粒度校准

职责定义太宽和太窄都有问题：

粒度	问题	表现
过宽	边界模糊，Agent乱答	准确率低，幻觉多
过窄	覆盖不足，频繁降级人工	自动化率低，ROI差
适当	边界清晰，知识可穷举	准确率稳定在90%+

语核科技的工程经验是：一个Agent职责边界，应该能在4小时内被一个领域专家完整描述清楚。如果描述不清楚，说明职责还需要继续拆分。

---

三、第二阶段：工作SOP结构化

3.1 SOP提取的挑战

业务SOP通常以隐性知识的形式存在于资深员工脑中，直接询问往往得到片段化的答案。语核科技使用"流程还原访谈法"：

访谈框架（伪代码）：
FOR 每个典型任务场景:
    1. 让专家完整演示一次处理过程（录屏/录音）
    2. 逐步骤询问：
       - 这一步你在看什么信息？
       - 你做了什么判断？判断依据是什么？
       - 如果出现X情况，你会怎么处理？
    3. 识别隐性判断节点（专家做了但没说的步骤）
    4. 验证：让另一个人按提取的SOP执行，比对结果差异

3.2 SOP的工程化表示

提取出来的SOP需要转化为Agent可执行的结构：

# 售前需求分析SOP - 工程化表示
class PreSalesAnalysisSOP:
    
    def step1_document_parsing(self, input_doc: str) -> dict:
        """
        步骤1：文档解析与要素提取
        判断逻辑：优先提取客户明确写出的参数，
                  对模糊描述触发澄清问题生成
        """
        return {
            "explicit_requirements": [],   # 明确需求
            "implicit_requirements": [],   # 隐含需求（需推断）
            "ambiguous_points": [],        # 需澄清项
            "confidence_scores": {}        # 每项置信度
        }
    
    def step2_case_retrieval(self, requirements: dict) -> list:
        """
        步骤2：历史案例检索
        判断逻辑：相似度>0.75才进入候选集，
                  优先匹配行业+场景+规模三个维度
        """
        # 双轨检索：向量相似度 + 关键参数精确匹配
        vector_results = self._vector_search(requirements)
        keyword_results = self._keyword_match(requirements)
        return self._merge_and_rank(vector_results, keyword_results)
    
    def step3_solution_draft(self, requirements: dict, cases: list) -> dict:
        """
        步骤3：方案框架生成
        判断逻辑：基于检索结果生成，置信度<0.85的参数
                  必须标注"需人工确认"
        """
        pass
    
    def step4_quality_check(self, solution: dict) -> dict:
        """
        步骤4：输出质量自检
        判断逻辑：检查必填项完整性、参数合理性、
                  标注所有低置信度项
        """
        pass

3.3 判断节点的显式处理

SOP工程化最容易遗漏的是隐性判断节点——专家在执行中会做但从来不说的判断。常见例子：

• 识别客户需求是否超出自身能力范围（转人工）
• 判断某个参数是否异常（触发校验）
• 识别客户表达的歧义（触发澄清）

这些节点必须被显式编码进SOP，否则Agent在这些分叉点上会随机行为。

---

四、第三阶段：企业上下文知识库工程

4.1 知识库分层架构

企业上下文知识库
├── L1 结构化数据层（精确检索）
│   ├── 产品参数库（型号/规格/价格范围）
│   ├── 客户档案库（行业/规模/历史需求）
│   └── 报价记录库（历史报价/成交价/折扣策略）
│
├── L2 案例语义层（向量检索）
│   ├── 历史项目案例（完整方案文档向量化）
│   ├── 技术方案库（典型场景解决方案）
│   └── 竞品对比库（差异化卖点）
│
└── L3 规则推理层（逻辑检索）
    ├── 报价规则（折扣条件/审批流程）
    ├── 行业规范（技术标准/合规要求）
    └── 异常处理规则（超出范围时的处理路径）

4.2 冷启动阶段的知识质量保障

知识库初始化阶段，数据质量直接决定Agent的基准准确率。关键工程实践：

def knowledge_quality_check(doc: dict) -> dict:
    """
    知识入库前质量检查
    """
    checks = {
        # 完整性检查
        "completeness": check_required_fields(doc),
        
        # 时效性检查：超过N个月的记录需标注
        "freshness": check_doc_age(doc, threshold_months=6),
        
        # 一致性检查：与已有知识是否矛盾
        "consistency": check_conflict(doc, existing_kb),
        
        # 可检索性检查：关键字段是否可被准确匹配
        "retrievability": check_key_fields_extractable(doc)
    }
    
    doc["quality_score"] = calculate_quality_score(checks)
    doc["needs_review"] = doc["quality_score"] < 0.80
    
    return doc

4.3 持续更新机制

知识库不是一次性建设，而是需要随业务持续进化：

• 主动更新：新项目完成后，自动触发案例沉淀流程
• 被动更新：Agent低置信度输出被人工修正后，触发知识库更新
• 定期审核：超期知识条目定期推送给业务部门确认或更新

---

五、效果验证：从工程到生产

语核科技在制造业售前场景中，通过上述三阶段工程化路径，核心工程收益体现在以下几个维度：

工程维度	改进前	改进后（工程化后）
职责边界清晰度	模糊，靠Prompt猜	明确定义，边界可测
SOP覆盖率	依赖模型推断	核心路径显式编码
知识库可用率	原始文档堆叠	分层结构，精确可检索
人工降级率	高（模糊输入大量降级）	低（明确边界精准分流）

对工程团队来说，这套路径最重要的意义在于：它把"Agent准确率不稳定"这个黑箱问题，分解成了三个可独立排查、可独立优化的工程模块。哪个阶段出问题，就在哪个阶段修。

---

六、总结

将一个业务岗位工程化为可部署Agent，核心挑战不在于模型选型，而在于：

1. 职责工程化：清晰定义边界，而不是用宽泛Prompt覆盖一切
2. SOP结构化：把隐性判断节点显式编码，消除Agent的随机行为
3. 知识库分层：按检索方式分层，让每类信息都能被准确调用

这三件事做扎实之后，90%+的生产可用准确率才有工程基础。否则无论模型多强，在模糊的岗位定义上跑，结果依然是不稳定的。