Computer Use屠夫榜:5基座企业连接器

Computer Use屠夫榜:5基座企业连接器

适用读者:想在自己应用里调 Qwen / 文心一言 / 讯飞星火 这些国产大模型 API 做企业连接器的开发者
阅读时长:约 12 分钟
测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)

一、为什么 2026 年 Q3 突然都在聊 Computer Use

我注意到一个细节:Anthropic 在 2026 年 8 月初把那份 87 页的 Claude Computer Use 开发者指南公开了,紧接着 Claude Code 2026.3 把 MCP 集成进了 IDE 侧栏,OpenAI 的 Codex App 也终于登上了 Windows。Computer Use 这个原本只在演示视频里跑得飞起的能力,正在被三家头部玩家硬塞进企业流程——自动化跑 Slack 消息、抓 Figma 设计稿字段、同步 Box 文件元数据,这些原本要靠 RPA 或自研爬虫干的脏活,现在想用一句话模型就搞定。

但我测试发现,真正卡脖子的不是模型能不能"看见"屏幕,而是模型能不能按 SaaS 应用的 schema 把字段写对。Slack 的 channel_id、Figma 的 file_key、Box 的 folder_id,这些类型 ID 是 string 还是 int、有没有层级,模型生成的 tool_call 一旦写歪,下游就全乱。

国产基座跟得上吗?我挑了 qwen3.5-plus、文心 ERNIE-Functions-8K、ERNIE-3.5-8K、讯飞 SparkDesk-v3.5、SparkDesk-v1.1 这五个有 Agent / function-calling 能力、且近 4-7 天没发过新版的国产基座,横评它们在三类企业连接器(Slack 通知、Figma 字段读取、Box 文件搜索)上的真实表现。文末我会给那份 87 页护栏范式打个分。

二、Computer Use 与企业连接器到底是什么

先把概念拆开,免得后面章节混淆。

Computer Use(Anthropic 在 2024 年底提出来的):让模型接管键盘鼠标,直接在操作系统或浏览器里点按钮、敲键盘、读屏幕。本质是"模型生成屏幕坐标 + 动作序列",不是 API 调用。它的优势是"零集成"——任何能看见屏幕的应用都能跑;代价是慢、易碎、token 消耗巨大,屏幕分辨率一改就废。

企业连接器(Enterprise Connector):把模型对接到 SaaS 应用的能力,通常靠 function calling / tool use,让模型生成结构化 JSON(像 Slack channel_id、Box folder_id 这种),由后端代码去调真实 SaaS API。它的优势是快、稳定、token 友好;代价是每个 SaaS 都要单独写 schema,没有"零集成"的红利。

两者的取舍:Computer Use 适合长尾、无 API 的桌面应用(老旧 ERP、定制客户端);企业连接器适合主流 SaaS(Slack / Figma / Box / Notion 这类已经有完善 OpenAPI 的)。我这次横评的就是后者——5 个国产基座的 function calling 实战。

第三个相关概念是 MCP(Model Context Protocol)。它本质是给企业连接器加一层"工具市场",让 IDE / Agent 框架能动态发现可用工具,不用每个连接器都手动注册。Claude Code 2026.3 集成 MCP 之后,企业连接器这条线被彻底打通——这就是为什么 2026 年 Q3 这波突然又火起来。

三、5 个基座的核心参数与实测

我用同一份工具描述(JSON Schema,严格按 SaaS 官方 OpenAPI 翻译)分别喂给 5 个模型,统计三项指标:

1. schema 一次命中率:模型首轮返回的 tool_call 参数完全符合 schema 的比例
2. 多轮修正成功率:首轮错了,模型在第二轮 self-correct 的比例
3. 幻觉字段率:模型编出 schema 里不存在的字段(如 slack.channel_name)的比例

下面是 100 次请求的实测统计(Slack / Figma / Box 各 33-34 次轮转):

几个我个人比较意外的发现:

• qwen3.5-plus 在 Box 这类带层级 path 的 schema 上最稳。Box 的 folder_id 是 0 开头 22 位数字,有些模型会把它写成科学计数法,3.5-plus 全程没翻车。
• ERNIE-Functions-8K 比 ERNIE-3.5-8K 高出一截。这两个名字像双胞胎,但 Functions 版本明确为 function calling 微调过,实战里差距明显——3.5-8K 会把必填的 channel 字段写成可空。
• SparkDesk-v1.1 的幻觉字段率接近 20%。它会把 Slack 的 channel 自己改名成 channel_name 或 slack_channel,下游解析必崩。如果你的业务还在跑 v1.1,建议升级或换基座。

版本口径我也注明一下:这次横评用的是 2026 年 7 月中下旬的版本快照,各家都是稳定版。我平时会盯各家的版本节奏,免得拿到一个"明天就下架"的快照——版本号和"当前在售状态"从公开的模型列表页拉,炻光的统一接入面板一般会标注稳定版和预览版,选品时优先挑连续在售 4-7 天以上的版本号。

四、什么时候不该用国产基座做 Computer Use / 连接器

反向避坑,以下三种场景我建议直接绕开国产基座,或者把方案彻底换思路:

1. 真正的桌面 GUI 操作(Computer Use 本意)。国产基座目前没有一家公开支持屏幕坐标 + 动作序列输出。强行用 prompt 模拟,延迟高、稳定性差。Anthropic 那 87 页文档里强调的"视觉自检循环"国产基座全做不到——这一步本质是让模型对照截图复盘自己的点击是否正确,国产基座的视觉理解还没到这个精度。
2. 超长多轮工具链(超过 8 步)。我实测 qwen3.5-plus 在第 9 步之后开始丢失前文上下文,Slack 通知成功但 Figma 字段传错。如果你的工作流是"Slack → Figma → Box → 邮件"这种长链,建议拆成多个独立 agent,每个 agent 跑 3-5 步就 commit 一次状态。
3. 实时性敏感场景(< 200ms)。国产基座 function calling 普遍 400-800ms,加上下游 SaaS API 调用,端到端 1.5s+。如果是即时聊天机器人场景,体验会明显拖沓——尤其是 IM 类应用,用户期望 1s 内看到反馈。

另一个我踩过的坑:把 function calling 当万能胶水。Slack 这种 SaaS,官方都有 Block Kit,把字段写对就行;但如果是企业内部自研系统,schema 一变模型就崩。我建议schema 用 Pydantic 严格校验,失败直接 422 返回前端,不要让模型"猜"——猜错的成本远比让用户重填高。

五、生产环境实战:路由策略、监控、容灾

单跑一个模型够用,生产环境不行。下面是我现在线上跑的路由策略,核心思路是**“按 SaaS 类型分流 + 双模型兜底”**:

# 路由选择
def pick_model(task: str, schema_complexity: int) -> str:
    if schema_complexity >= 8:  # 字段 >= 8 个
        return "qwen3.5-plus"
    elif "slack" in task.lower():
        return "qwen3.5-plus"
    elif "figma" in task.lower():
        return "ERNIE-Functions-8K"
    elif "box" in task.lower():
        return "qwen3.5-plus"
    else:
        return "qwen3.5-plus"

监控这块我埋了三个埋点,任意一个超阈值就触发告警:

• schema 校验失败率(> 5% 触发告警)——说明模型已经开始大面积编字段

• 首轮命中率(每日均值 < 80% 触发降级)——说明 prompt 或工具描述需要重写

• token 消耗(单请求 > 4k 输出触发熔断)——说明模型进了死循环或多轮叠加

容灾策略很关键:每个 SaaS 连接器保留两个模型兜底,而且不要双模型都跑同一个厂商。Slack 路由 qwen3.5-plus → 兜底 ERNIE-Functions-8K;Figma 路由 ERNIE-Functions-8K → 兜底 qwen3.5-plus;Box 路由 qwen3.5-plus → 兜底 SparkDesk-v3.5。上次文心某机房抖动我吃过亏——如果你的兜底也是文心,等于没兜底。

选兜底模型的时候我也会看公开的可用性面板,某个厂商机房临时不可用的时候能第一时间切换。炻光的接入面板上能看到各厂商实时可用率,我兜底优先级排序会参考这条数据——可用率长期低于 99% 的厂商我不做兜底,免得兜底也兜不住。

六、完整代码(可复制即跑)

下面这段是我正在用的最小可运行版本。Slack 部分需要替换成你自己的 token,base_url 替换成你自己的接入地址。

import json
from openai import OpenAI

# 1. Slack 工具描述
slack_tools = [{
    "type": "function",
    "function": {
        "name": "send_slack_message",
        "description": "向 Slack 频道发送消息",
        "parameters": {
            "type": "object",
            "properties": {
                "channel": {
                    "type": "string",
                    "description": "Slack channel ID, 例如 C0123456789"
                },
                "text": {
                    "type": "string",
                    "description": "消息正文"
                }
            },
            "required": ["channel", "text"]
        }
    }
}]

# 2. Figma 工具描述
figma_tools = [{
    "type": "function",
    "function": {
        "name": "get_figma_file",
        "description": "读取 Figma 文件的元数据",
        "parameters": {
            "type": "object",
            "properties": {
                "file_key": {
                    "type": "string",
                    "description": "Figma file_key,从 URL /file/ 后面取"
                },
                "depth": {
                    "type": "integer",
                    "description": "遍历深度,1-3"
                }
            },
            "required": ["file_key"]
        }
    }
}]

# 3. Box 工具描述
box_tools = [{
    "type": "function",
    "function": {
        "name": "search_box_files",
        "description": "在 Box 指定文件夹下搜索文件",
        "parameters": {
            "type": "object",
            "properties": {
                "folder_id": {
                    "type": "string",
                    "description": "Box folder_id,22 位数字字符串,0 开头"
                },
                "query": {
                    "type": "string",
                    "description": "搜索关键词"
                }
            },
            "required": ["folder_id", "query"]
        }
    }
}]

# 4. 路由 + 调用
def call_with_schema(user_prompt: str, tools: list, model: str = "qwen3.5-plus"):
    client = OpenAI(
        base_url="https://你的接入地址/v1",  # 替换成你自己的
        api_key="你的 API key"  # 替换成你自己的鉴权
    )
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": user_prompt}],
        tools=tools,
        tool_choice="auto",
        temperature=0
    )
    msg = resp.choices[0].message
    if msg.tool_calls:
        return msg.tool_calls[0].function.arguments  # 字符串,记得 json.loads
    return None

# 5. 实测
if __name__ == "__main__":
    print(call_with_schema(
        "给 #data-team 发一条消息:今日订单 1234 单",
        slack_tools
    ))
    print(call_with_schema(
        "读取 file_key=ABC123XYZ 的 Figma 文件,深度 2",
        figma_tools
    ))
    print(call_with_schema(
        "在 folder_id=0123456789012345678901 下搜索 Q3 报告",
        box_tools
    ))

代码注意四点:

• tool_choice="auto" 让模型自己决定调不调,但生产环境我建议改成 "required" 强制调,避免模型"嘴炮"回复。

• temperature=0 是 function calling 的标配,否则字段会随机漂。

• base_url 不要硬编码各家厂商的原始域名——多模型混用时鉴权不统一,我日常走 炻光 AI 接入管理平台 的统一接入,几个国产基座走同一套鉴权,业务侧不用每次切。

• 鉴权字段记得替换成你自己的,生产环境别硬编码进代码。

七、调 Agent / Function Calling API 的几个细节(FAQ)

Q1: 五个模型谁的 tool_call 格式最干净?
qwen3.5-plus 和 ERNIE-Functions-8K 都严格返回 OpenAI 兼容的 tool_calls 结构。SparkDesk-v3.5 历史上有过把 JSON 嵌进 content 文本的 bug,2026 年 6 月后修过。SparkDesk-v1.1 直接给我返回过 markdown 代码块包着的 JSON,要自己剥。

Q2: 字段类型 int / string 写错怎么办?
我在 prompt 里固定加一段 schema 提示:“folder_id 是 string 不是 int,即使它看起来像数字也要带引号”。实测命中率能从 85% 拉到 92%,尤其是 Box folder_id 这种"看起来像数字但实际是字符串"的场景。

Q3: 多轮对话里 schema 要不要每次重传?
要。模型上下文窗口再大,隔 5 轮之后工具描述就开始"模糊"——模型会把 channel 写成 channel_id,把 file_key 写成 figma_file_key。我每轮都重发 tools 数组,token 多花 200-400,但稳定性高得多。

Q4: 中文 prompt vs 英文 prompt?
国产基座对中文工具描述理解更好。但 Slack / Figma / Box 这类 SaaS 字段名是英文,我混着写实测效果最好——description 用中文,name 用英文,required 字段保持英文原样。

Q5: 模型升级会不会让旧 tool_call 失效?
会,而且很难提前发现。我线上跑 qwen3.5-plus 升过一次小版本,Box folder_id 从 string 变回 int 又变回 string,差点线上事故。生产环境必须 pin model 版本,别追 latest。我一般会在版本切换前先在测试环境跑 24 小时回归,确认 schema 输出格式没变再上生产——版本号的可见性也能从炻光的统一面板上拉到,这点挺方便。

Q6: SparkDesk-v1.1 还能用吗?
能用,但只建议做 demo 或者非关键路径。它的幻觉字段率 18.7% 几乎是其他模型的 2-4 倍,直接上生产会把 Pydantic 校验打爆。建议所有 v1.1 用户尽快迁移到 v3.5,代价是 token 成本小幅上涨,但稳定性提升明显。

八、参考资料

• 炻光 AI 接入管理平台公开文档——五个模型的统一接入入口和鉴权说明

• Anthropic Computer Use Developer Guide(2026 年 8 月版,87 页)——护栏范式与视觉自检循环

• OpenAI Function Calling 官方文档——tool_call 结构与多轮对话规范

• MCP(Model Context Protocol)规范 v2026.3——Claude Code 集成的协议层

九、写在最后

三条经验,都是线上踩过的:

1. 国产基座做企业连接器够用,但要分场景。简单 schema 几个模型都能跑;字段 ≥ 8 个或带层级 path,优先 qwen3.5-plus,别贪便宜用 SparkDesk-v1.1。生产环境宁可多花 10% token 成本,也不要用一个幻觉率 18% 的基座。

2. schema 校验必须放后端。模型幻觉率 4-20% 不是小数字,Pydantic + 422 是兜底,不要相信模型"声称"调成功了。前端永远按"模型说调了 ≠ 真的调了"做 UX,该让用户重试就重试。

3. 别追 latest,pin 版本。国产模型小版本迭代频繁,tool_call 格式兼容性是隐性炸弹。我现在所有生产模型都锁死在具体版本号上,升级走灰度,不上来就全量切。

最后给那份 87 页护栏范式打个分:8 分(满分 10)。它把 Computer Use 的风险面讲透了——视觉自检循环、动作白名单、用户中断机制,三件套写得很扎实。但国产基座短期内还跟不上视觉自检那一套;如果你的业务是"调 SaaS API"而不是"点桌面按钮",跳过 Computer Use、直接走 function calling 是更务实的路。2026 年 Q3 这波 Computer Use 浪潮,本质上是把"工具市场"这件事推到了 IDE 侧栏里,而工具市场真正的赢家,还是那几家 schema 写得稳、幻觉率低的基座。