百度发布首个企业级Skill标准，AI Agent落地进入“标准化“时代？一个一线开发者的冷思考

黑箭科技

272人浏览 · 2026-07-11 16:39:55

黑箭科技 · 2026-07-11 16:39:55 发布

百度AI DAY上发布的"搭子DuMate"企业版和Skill接入标准，标志着AI Agent从"能用"走向"好用"。但企业真正需要的，远不止一个标准接口。

一、百度这次到底发了什么

昨天百度AI DAY的信息量挺大的，但如果只挑一条跟企业开发最相关的，我会选这个——

百度正式发布"搭子DuMate"企业版AI智能体，同步推出首个企业级Skill接入标准。

先说DuMate企业版本身。核心能力其实就三件事：

对接企业内部系统：OA、CRM、ERP、HR……不是做个API调用就完事，而是要深入业务系统的权限体系和数据模型
员工身份透传：AI帮你查CRM客户数据时，走的是你自己的账号权限，不会越权看到别人的数据
行级数据权限管控：同样是"查本月销售额"，销售总监看到全国数据，区域经理只看到自己大区的数据——这种粒度的权限控制

坦白说，这些能力单拿出来都不算新鲜。OA系统做了二十年的权限管理，CRM的数据隔离也是标配。但当AI Agent开始要"替员工干活"的时候，这些问题就从"理论上有"变成了"必须解决"。

再看Skill接入标准。百度的思路是：定义一套标准化的Skill接口规范，让不同厂商、不同团队开发的AI能力模块可以即插即用地接入DuMate平台。目前已经在百度内部跑通，覆盖多个行业场景。

这个动作释放的信号很明确：百度想在企业AI Agent领域做"标准制定者"，而不只是产品提供者。

二、为什么Skill标准化是必然的

作为一个带团队做了两年AI Agent落地的开发者，我对"标准"这个东西又爱又恨。

爱的是——没有标准的时候，每个项目都在重复造轮子。

去年我们给一个制造业客户做AI助手，需要对接他们的MES系统。客户说"我们有标准API"，结果到现场一看，所谓的"标准API"是三年前一个外包团队写的，文档缺失，接口命名混乱，连鉴权方式都是自定义的。光是搞清楚怎么调用一个"查询工单状态"的接口，就花了整整三天。

恨的是——标准这东西，制定容易落地难。

百度这次推Skill标准，优势在于它有足够多的内部场景可以验证。百度搜索、百度智能云、百度网盘……内部产品线够多，覆盖的场景够复杂。但企业市场的复杂性远超想象：

不同行业的合规要求不同（金融行业的数据脱敏 vs 制造业的工艺参数保护）
不同企业的IT基础设施差异巨大（有的用SaaS，有的还在自建机房）
不同系统的集成方式五花八门（REST API、SOAP、数据库直连、文件交换……）

一个标准想要"通吃"所有场景，基本不可能。更现实的路径是：先定义核心协议，再按行业做扩展。 类似Kubernetes的做法——核心API统一，具体实现通过CRI、CSI这些接口扩展。

从百度披露的信息看，他们目前的Skill标准更像是"第一阶段"，先把最常见的能力类型（数据查询、流程触发、内容生成）标准化，后续再逐步扩展。这个节奏是对的。

三、企业AI Agent落地的四个真问题

百度的Skill标准解决的是"能力接入"问题，但企业AI Agent落地远不止于此。根据我们团队这一年多在多个行业的实战经验，真正卡脖子的往往是这四个问题：

问题一：权限不是"有或没有"，而是"粒度够不够细"

大多数OA和CRM系统的权限模型是为"人"设计的，不是为"AI Agent"设计的。

举个例子：一个销售助理Agent需要帮员工查询客户合同信息。在传统权限体系下，要么给Agent一个"查询合同"的角色权限（太粗，可能看到所有合同），要么不给权限（太细，Agent什么都干不了）。

行级权限管控才是正解——Agent继承操作者的身份，只能看到这个人有权限看的数据。百度DuMate提到的"员工身份透传"就是在解决这个。

技术上怎么实现？我们在实际项目中用过两种方案：

方案A：Token透传模式

用户 -> AI Agent -> 获取用户Token -> 携带Token调用业务API -> 业务系统按Token鉴权

这种方式最干净，但要求业务系统支持Token级别的鉴权。如果老系统只支持Session或Cookie，就需要加一层适配。

方案B：权限映射模式

用户 -> AI Agent -> 查询用户权限矩阵 -> Agent按权限范围构造查询条件 -> 调用业务API

这种方式兼容性好，但需要维护一份"用户-权限"的映射关系，而且权限变更时要实时同步。

两种方案各有适用场景，没有银弹。关键是根据企业的IT现状选择，不要为了"优雅"强推某种方案。

问题二：上下文管理比你想象的难十倍

ChatGPT式的单轮对话很简单，但企业场景下的上下文管理复杂得多：

跨系统上下文：用户先问CRM里的客户信息，再问OA里的审批进度，Agent需要把两个系统的数据关联起来
长周期上下文：一个采购审批流程可能持续两周，Agent需要记住每一步的进展和决策依据
多角色上下文：同一个流程中，申请人、审批人、财务看到的是不同的信息，Agent需要按角色切换视角

我们之前在做一个审批助手的Agent时，光上下文管理模块就迭代了四个版本。最初用的简单对话历史，后来发现根本hold不住——用户三天前说的一个条件，在今天的对话中还影响着决策逻辑。

最后我们的方案是：分层上下文管理。

┌─────────────────────────────────────────┐
│            全局上下文层                   │
│  用户身份、角色、权限、偏好设置           │
├─────────────────────────────────────────┤
│            业务上下文层                   │
│  当前流程状态、关联数据、历史决策          │
├─────────────────────────────────────────┤
│            对话上下文层                   │
│  近期对话历史、意图缓存、指代消解          │
└─────────────────────────────────────────┘

每一层有独立的存储和更新策略。全局上下文变化频率最低但影响面最大，对话上下文变化最快但生命周期最短。这种分层设计让我们可以针对不同层做优化——比如全局上下文用缓存，对话上下文用滑动窗口。

问题三：容错机制决定Agent能不能"上生产"

Demo阶段的AI Agent看起来都很酷，但一上生产就各种问题。最大的差异就在于容错。

大模型的输出是不确定的。同一个prompt，今天返回JSON格式正确，明天可能多一行解释文字。如果业务系统 expecting 严格的JSON，一个字段格式错误就导致整个流程崩溃。

我们在生产环境踩过的坑包括但不限于：

LLM返回的日期格式不稳定（"2026-07-10"和"2026年7月10日"混着来）
数值字段偶尔带千分位逗号（“1,000,000” vs “1000000”）
长文本输出被截断导致JSON不完整
多轮对话中Agent"忘记"前面说过的约束条件

解决方案不是什么高深技术，就是防御性编程+多层校验：

# 一个简单但关键的输出校验函数
def validate_agent_output(raw_output, schema):
    """校验Agent输出是否符合预期schema"""
    try:
        # 第一层：尝试修复常见的格式问题
        cleaned = clean_json_string(raw_output)
        parsed = json.loads(cleaned)
    except json.JSONDecodeError:
        # 第二层：修复失败，尝试从原始文本中提取关键信息
        parsed = extract_from_raw_text(raw_output, schema)
    
    # 第三层：字段级校验
    for field, rules in schema.items():
        if field not in parsed:
            if rules.get('required'):
                raise ValidationError(f"缺少必填字段: {field}")
        else:
            validate_field(parsed[field], rules)
    
    return parsed

这种东西不性感，但决定了Agent能不能真正在生产环境跑起来。

问题四：效果评估缺乏统一标准

“AI Agent到底做得好不好？”——这可能是企业落地过程中最难回答的问题。

传统的软件测试有明确的pass/fail标准，但AI Agent的输出是概率性的。“帮我查一下最近一周的销售数据并做个分析”——这个任务的"正确答案"是什么？不同人可能有不同的期望。

我们目前的评估体系大概是这样的：

评估维度	指标	评估方式
意图识别准确率	正确识别用户意图的比例	人工标注测试集
任务完成率	成功完成端到端任务的比例	自动化测试+人工验证
数据准确性	返回数据与实际数据的一致性	与业务系统数据交叉验证
响应时间	从用户提问到返回结果的时间	自动化监控
用户满意度	用户对结果的满意程度	使用后的评价反馈

说实话，这套体系还不完美。但至少让团队有了一个相对客观的衡量标准，而不是靠"感觉"判断Agent好不好用。

四、一个制造业客户的落地实践

说了这么多理论，分享一个实际案例。

今年上半年，我们给一家年产值30亿左右的制造业企业做了AI Agent助手。这家企业的痛点很典型：

内部系统多（SAP、自研MES、OA、CRM），数据孤岛严重
管理层需要频繁查看各类报表，但数据获取效率低
一线员工需要查询工艺参数、设备状态等信息，但入口分散

我们的方案是搭建一个统一的AI Agent入口，对接四大系统。核心架构如下：

                    ┌─────────────┐
                    │   AI Agent  │
                    │   网关层     │
                    └──────┬──────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
     ┌──────┴──────┐ ┌────┴────┐ ┌──────┴──────┐
     │  权限管理    │ │ 上下文   │ │  工具编排    │
     │  模块       │ │ 管理模块  │ │  引擎       │
     └──────┬──────┘ └────┬────┘ └──────┬──────┘
            │              │              │
     ┌──────┴──────────────┴──────────────┴──────┐
     │              Skill 接入层                   │
     ├─────┬──────┬──────┬────────┤
     │ SAP │ MES  │  OA  │  CRM   │
     └─────┴──────┴──────┴────────┘

几个关键设计决策：

1. Skill封装思路

每个业务系统的能力被封装成独立的Skill。比如SAP系统封装了"查询订单状态"“查询库存”"查询财务数据"等12个Skill。每个Skill有标准化的输入输出定义，但内部实现可以完全不同——有的走API，有的走数据库视图，有的甚至走RPA。

这和百度推的Skill标准化思路其实很接近。区别在于，我们是在单个企业内部做标准化，百度是想做跨企业的行业标准化。

2. 权限设计

采用了前面提到的"Token透传+权限映射"混合方案。对于新系统（SAP S/4HANA、新版OA）用Token透传，对于老系统（自研MES、老版CRM）用权限映射。

3. 上下文策略

管理层对话的上下文保留7天（因为决策周期长），一线员工对话的上下文保留2小时（因为查询通常是即时的）。不同角色的上下文策略不同。

上线三个月后的效果数据：