前言

在为多家制造业及科技企业落地AI数字员工的过程中，语核科技工程团队持续观察到一个现象：通用大模型在能力评测中表现优异，但一旦进入生产环境，可靠性问题就会显现。这些问题不是模型能力不足导致的，而是架构设计层面的缺陷——企业对AI的核心需求是确定性和可控性，而通用Agent的设计逻辑是在开放环境中最大化发挥能力，两者天然存在张力。

本文梳理了我们在工程实践中总结出的一套架构思路：以Skill机制替代纯Prompt工程，实现企业级AI Agent的可靠落地。

---

一、问题分析：生产环境的失控案例

在讨论架构方案之前，先看三个真实发生的失控案例，它们分别对应三类不同的架构缺陷。

1.1 自主执行失控

某团队部署了一个具备工具调用能力的AI Agent，用于完成一项从零开始的系统搭建任务。Agent表现得非常"勤奋"——自主检索资料、调用脚手架工具、编写并执行代码，连续运行将近两个小时。

最终交付的系统，和实际需求完全不符。

问题根源：任务目标描述不足以约束执行路径。Prompt定义了"做什么"，但没有定义"怎么验证中间结果是否对"以及"每一步的边界条件"。Agent在没有检查点的情况下自主推进，方向偏差在早期无法被发现，到结束时已无法挽回。

1.2 越权操作

另一个案例中，Agent被指派修复一段代码。Agent判断需要更多上下文，于是自主决定前往开源社区，以真实用户身份发帖提问获取输入——这触发了平台的风控机制，账号被封禁。

问题根源：工具调用权限未分级。Agent拥有"联网搜索"工具的调用权限，但没有区分"内部知识库检索"和"向外部平台发布内容"这两种性质完全不同的操作。所有网络操作被视为同等权限，导致越权动作在架构层无法拦截。

1.3 成本失控

第三个案例：高频工具链调用导致Token消耗在短时间内急剧增长，整个过程中没有任何预算监控或熔断机制——账单出来才知道发生了什么。

这三个案例共同揭示了企业AI Agent面临的四类生产风险：

风险类型	具体表现	架构缺失项
权限失控	调用了不该调用的接口/数据	工具权限分级机制
行为越界	执行超出预设范围的操作	操作类型审批层
成本失控	Token/API调用无预算上限	消耗监控与熔断
数据泄露	敏感业务信息流向外部	数据流向管控层

这四类风险，没有一项可以靠"换一个更好的大模型"来规避。 它们是架构设计问题。

---

二、Prompt工程的失效边界

Prompt工程（Prompt Engineering）是目前大多数企业AI项目的主要技术手段。其本质是通过精心设计的输入文本，引导模型在当前对话中给出期望输出。

Prompt工程的适用场景：单次任务、输出格式已知、上下文信息完整、无需持久化状态。

Prompt工程的失效条件（满足任意一项则不适用）：

# 以下场景中，纯Prompt方案将失效

失效条件 = {
    "多步骤状态管理": "任务跨越多个执行步骤，中间状态需要被追踪",
    "动态执行路径": "下一步动作依赖运行时信息，无法静态预定义",
    "工具权限管控": "需要调用外部工具，且不同工具的操作权限不同",
    "业务逻辑复用": "判断规则需要在多次执行中保持一致并可更新",
    "高代价错误": "输出错误会造成用户可见损失或不可回滚的副作用"
}

纯Prompt方案的根本局限在于：每次调用结束，上下文即归零。

这带来三个工程层面的问题：

1. 业务判断逻辑无法积累——每次从零开始，同样的错误会反复发生
2. 执行中间状态无法监控——黑盒运行，问题发现时为时已晚
3. 人工纠正无法沉淀——纠正了这一次，下次还是会犯同样的错

一个纯Prompt方案的AI系统，使用一万次之后和使用第一次的能力是相同的。这不是企业需要的工具形态。

---

三、Skill机制的架构设计

Skill机制的核心思路是：将可复用的业务判断逻辑封装为独立的可调用单元，与Prompt分离，允许独立更新、测试和版本追踪。

3.1 整体架构

┌─────────────────────────────────────────────────────────────┐
│                      企业AI Agent 架构                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌──────────────┐    ┌────────────────────────────────┐    │
│   │   任务输入    │───▶│          岗位化 Agent            │    │
│   │  (用户/系统)  │    │  - 岗位定义（职责与边界约束）   │    │
│   └──────────────┘    │  - 工具白名单（权限分级）       │    │
│                        │  - 输出规范（格式/内容约束）   │    │
│                        │  - 预算上限（Token熔断阈值）   │    │
│                        └──────────────┬─────────────────┘    │
│                                       │                      │
│                        ┌─────────────▼─────────────────┐    │
│                        │          Skill 调度层           │    │
│                        │   match_skill(task, context)   │    │
│                        └─────────────┬─────────────────┘    │
│                                      │                       │
│          ┌───────────────────────────┼───────────────────┐  │
│          ▼                           ▼                   ▼  │
│  ┌───────────────┐        ┌──────────────────┐  ┌───────────┐│
│  │  业务知识仓库  │        │    Skill 仓库     │  │  工具层   ││
│  │ (结构化资产)  │        │ (可复用判断逻辑)  │  │ (受权限控) ││
│  └───────────────┘        └──────────────────┘  └───────────┘│
│          │                           │                       │
│          └───────────────┬───────────┘                       │
│                          ▼                                   │
│                 ┌──────────────────────┐                     │
│                 │      执行追踪层        │                     │
│                 │  - 任务记录与回放     │                     │
│                 │  - 实时成本监控       │                     │
│                 │  - 人工纠正日志       │                     │
│                 │  - Skill进化触发     │                     │
│                 └──────────────────────┘                     │
└─────────────────────────────────────────────────────────────┘

3.2 Skill 数据结构设计

Skill的核心是将业务判断逻辑标准化为可存储、可检索、可版本化的数据对象：

from dataclasses import dataclass, field
from typing import List, Optional, Dict, Any
from datetime import datetime
from enum import Enum


class SkillStatus(Enum):
    DRAFT = "draft"           # 草稿，未经验证
    ACTIVE = "active"         # 生产可用
    DEPRECATED = "deprecated" # 已废弃，保留历史记录


@dataclass
class SkillExample:
    """Skill示例：正向样本和反向样本都需要"""
    input_context: Dict[str, Any]  # 触发此Skill时的典型输入
    expected_output: str           # 期望的输出
    is_counter_example: bool = False  # True = 边界/反向案例
    annotation: str = ""           # 人工备注（此例说明了什么规则）


@dataclass
class Skill:
    """
    可复用业务判断单元。
    
    与Prompt的核心区别：
    - 有版本管理，可以追踪历史变更
    - 有适用条件，避免在不匹配场景被错误调用
    - 有置信度阈值，低于阈值自动转人工
    - 有纠正计数，驱动持续进化
    """
    skill_id: str
    name: str
    description: str               # 解决什么类型的判断问题

    # 触发条件（匹配后调用此Skill）
    trigger_conditions: List[str]

    # 核心逻辑（自然语言描述，由LLM执行）
    judgment_logic: str
    examples: List[SkillExample] = field(default_factory=list)

    # 输出约束
    output_format: str = "text"
    confidence_threshold: float = 0.85  # 低于此值须转人工审核

    # 生命周期管理
    status: SkillStatus = SkillStatus.DRAFT
    version: str = "1.0.0"
    created_at: datetime = field(default_factory=datetime.now)
    updated_at: datetime = field(default_factory=datetime.now)

    # 质量追踪（核心指标）
    usage_count: int = 0
    correction_count: int = 0     # 人工纠正次数，越低质量越好
    last_corrected_at: Optional[datetime] = None

    @property
    def correction_rate(self) -> float:
        """纠正率 = 纠正次数 / 总调用次数"""
        if self.usage_count == 0:
            return 0.0
        return self.correction_count / self.usage_count

    def needs_evolution(self, threshold: int = 3) -> bool:
        """达到进化触发阈值时返回True，提示需要更新Skill逻辑"""
        return (
            self.correction_count > 0
            and self.correction_count % threshold == 0
        )

3.3 岗位化 Agent 的边界管理

"岗位化"的核心原则是：一个Agent的能力边界应该等同于一个真实岗位的职责边界，而不是"能做到的都可以做"。

以售前数字员工为例，其岗位定义如下：

from typing import Set
import functools


# 售前岗位定义示例
PRESALES_ROLE = RoleDefinition(
    role_name="售前数字员工",
    allowed_tools={
        "knowledge_base_search",    # 内部知识库检索（允许）
        "product_catalog_query",    # 产品目录查询（允许）
        "crm_lead_read",            # CRM线索读取（允许）
        "calendar_schedule",        # 日历安排（允许）
    },
    # 以下工具未在白名单内，调用将被架构层拦截
    # "external_web_post"         # 向外部平台发布内容（禁止）
    # "crm_lead_delete"           # 删除CRM数据（禁止）
    # "email_send_external"       # 对外发送邮件（需审批）

    forbidden_actions=[
        "承诺具体折扣比例",
        "修改已签署合同条款",
        "访问非当前线索的客户数据",
    ],
    escalation_conditions=[
        "客户要求定制化报价超出标准范围",
        "客户明确表达投诉意向",
        "涉及法律合规类问题",
        "单次对话轮数超过20轮仍未达成共识",
    ],
    budget_limit_per_task=0.5,    # 单任务Token预算上限（USD）
    max_autonomous_steps=8        # 最大自主执行步数
)


class ExecutionMonitor:
    """执行监控器：实时追踪成本与步骤，提供熔断能力"""

    def __init__(self, role: RoleDefinition):
        self.role = role
        self.current_cost = 0.0
        self.current_steps = 0
        self.execution_log = []

    def check_tool_permission(self, tool_name: str) -> bool:
        """工具调用前的权限校验，不在白名单内直接拦截"""
        allowed = tool_name in self.role.allowed_tools
        if not allowed:
            self.execution_log.append({
                "type": "permission_denied",
                "tool": tool_name,
                "step": self.current_steps
            })
        return allowed

    def check_budget_and_advance(self, estimated_cost: float) -> bool:
        """
        步骤执行前检查预算和步骤数限制。
        返回 False 时，Agent 应立即停止并转人工处理。
        """
        if self.current_cost + estimated_cost > self.role.budget_limit_per_task:
            self._record_circuit_break("budget_exceeded", estimated_cost)
            return False

        if self.current_steps >= self.role.max_autonomous_steps:
            self._record_circuit_break("max_steps_reached", estimated_cost)
            return False

        self.current_cost += estimated_cost
        self.current_steps += 1
        return True

    def _record_circuit_break(self, reason: str, cost: float):
        self.execution_log.append({
            "type": "circuit_break",
            "reason": reason,
            "accumulated_cost": self.current_cost,
            "steps_taken": self.current_steps
        })
        # 实际实现中触发告警并创建人工介入任务

3.4 Skill 的持续进化机制

Skill机制与Prompt最本质的差别在于：人工纠正可以被结构化记录，并驱动Skill自身的迭代更新。

class SkillEvolutionEngine:
    """
    Skill进化引擎。
    
    核心流程：
      人工纠正一次 → 记录纠正日志
      纠正积累到阈值 → 生成进化建议
      人工审核通过 → 发布新版本Skill
    """

    EVOLUTION_THRESHOLD = 3  # 同类纠正N次后触发进化建议

    def __init__(self, skill_repo, review_queue):
        self.skill_repo = skill_repo
        self.review_queue = review_queue  # 人工审核队列

    def record_correction(
        self,
        skill_id: str,
        wrong_output: str,
        correct_output: str,
        context: Dict[str, Any]
    ) -> None:
        """记录一次人工纠正，并判断是否触发进化"""
        skill = self.skill_repo.get(skill_id)

        correction_record = {
            "wrong": wrong_output,
            "correct": correct_output,
            "context": context,
            "timestamp": datetime.now().isoformat()
        }
        skill.correction_count += 1
        skill.last_corrected_at = datetime.now()

        # 新增纠正样本到Skill示例库（作为counter_example）
        skill.examples.append(SkillExample(
            input_context=context,
            expected_output=correct_output,
            is_counter_example=True,
            annotation=f"纠正：原输出为「{wrong_output[:50]}...」"
        ))

        # 检查是否触发进化
        if skill.needs_evolution(self.EVOLUTION_THRESHOLD):
            self._trigger_evolution_review(skill)

        self.skill_repo.save(skill)

    def _trigger_evolution_review(self, skill: Skill) -> None:
        """
        调用LLM分析近期纠正日志，生成Skill更新建议，
        推入人工审核队列（不自动上线，人工确认后才生效）
        """
        recent_corrections = [
            ex for ex in skill.examples
            if ex.is_counter_example
        ][-self.EVOLUTION_THRESHOLD * 2:]  # 取最近N条

        # 伪代码：调用LLM提炼规律
        # evolution_prompt = f"""
        # 以下是Skill「{skill.name}」的最近纠正记录：
        # {format_corrections(recent_corrections)}
        #
        # 请分析纠正规律，提出对judgment_logic的具体修改建议。
        # 输出格式：{{"analysis": ..., "suggested_update": ...}}
        # """
        # suggestion = llm.generate(evolution_prompt)
        # self.review_queue.push(skill.skill_id, suggestion)
        pass

---

四、效果对比

以企业售前场景为例，对比纯Prompt方案与Skill架构方案在真实生产环境中的关键指标（数据来自真实部署环境，非精选测试集）：

维度	纯Prompt方案	Skill架构方案
输出一致性	同类问题输出不稳定	Skill约束下输出稳定
同类错误复发率	无改善机制（每次归零）	纠正后可沉淀，逐步降低
权限越界事件	依赖Prompt约束（可绕过）	架构层拦截，无法绕过
成本可预期性	无预算控制	单任务成本上限可配置
新员工使用门槛	需重新摸索业务逻辑	可直接调用Skill仓库
售前单人可跟进线索量	基准值	扩展至原来的 2倍以上

最后一项数据来自真实客户售前场景的部署结果：在目标清晰、输出可量化的岗位上，Skill架构带来的可靠性提升使工程师可以在保持质量的前提下并行处理更多任务。这不是"AI回答得更准"，而是系统整体执行可靠性提升带来的人效释放。

---

五、总结与后续方向

本文从三个真实的生产失控案例出发，分析了Prompt工程在企业场景的架构失效边界，提出了以Skill机制为核心的岗位化Agent架构：

• Skill = 可复用业务判断单元：有版本管理、置信度阈值、人工纠正驱动的进化机制
• 岗位化Agent = 有工具白名单 + 操作边界 + 成本熔断的执行主体：不是"通用助手"，而是有明确职责的数字员工
• 执行追踪层 = 所有操作有记录，人工纠正可沉淀：让系统越用越懂业务，而不是每次从零开始

当前架构仍有若干开放问题值得进一步探索：

1. 跨岗位Skill复用：不同岗位Agent之间共享通用判断逻辑时的版本隔离策略
2. Skill冲突解决：多个Skill对同一输入有不同建议时的优先级与合并机制
3. 自动化Skill提炼：从大量执行日志中自动识别可抽象为Skill的重复模式，降低人工整理成本

欢迎有类似工程实践的同学在评论区交流。