企业 AI 正从“聊天问答”走向“直接产出工作成果”。Cloudflare 开源的 Cloudflare OS，试图把企业知识、专业经验、系统连接器和自动化流程组合成一套可编排的工作平台：AI 只在需要判断和生成的环节介入，确定性的步骤交给程序完成，最终产出可交付、可复用、可分享的工作软件。
从提示词转向能力组合
Cloudflare OS 的关键思路不是给模型一个更长的提示词，而是把企业工作拆成一组明确的能力。一个能力可以代表读取知识库、查询业务系统、执行计算、生成文档，或调用经过授权的外部连接器。
这种能力模型有几个直接价值：
- 边界清晰：每项能力可以独立定义输入、输出、权限和失败处理。
- 流程可控：确定性的查询、校验和格式化不必消耗模型 Token。
- 知识有依据：生成内容可以绑定企业知识、内部方法论和授权数据源。
- 软件可复用：个人搭建的工作工具可以定制，也可以共享给团队继续改造。
例如，一个“客户周报生成器”不应让模型自行猜测数据来源。更可靠的流程是：从 CRM 读取本周机会，从工单系统读取风险，从知识库读取报告模板，程序先完成聚合和校验，模型只负责提炼变化、解释原因和生成自然语言总结。
AI 只处理需要判断的部分
企业自动化的成本通常不只来自模型调用，还包括错误重试、上下文过长、数据重复传递和人工复核。能力化设计可以把工作流拆成两类步骤：
- 确定性步骤：权限检查、数据查询、去重、排序、金额计算、格式校验和文件写入。
- 智能步骤：摘要、分类、异常解释、方案比较和面向人的表达。
可以这样实践：先用代码把数据收集和清洗固定下来，再把结构化结果交给 AI。这样既减少 Token 消耗，也让错误更容易定位。对于金额、权限、合规标签等关键结果，不应把最终决定交给模型，而应由规则或人工审批完成。
安全沙箱让工作软件更容易落地
企业工作软件往往需要访问内部知识和系统连接器，同时又不能让自动化逻辑无限制地触碰生产环境。Cloudflare OS 摘要中强调的安全沙箱，适合承担这类隔离职责：工作流在受控环境中运行，能力通过显式授权访问数据或执行动作。
落地时应把“能做什么”写成配置，而不是隐藏在提示词里。至少需要明确：
- 能力允许访问哪些数据源；
- 是否只读，还是允许写入；
- 单次调用的记录、超时和重试策略；
- 哪些动作必须经过人工确认；
- 生成结果如何保留来源和审计信息。
下面是一个概念性的能力清单示例。它不是 Cloudflare OS 的官方配置格式，而是可以用于设计类似系统的最小模型。运行前请根据实际平台改成对应的 API 或配置格式。
name: customer-weekly-brief
version: 1
sandbox:
network: restricted
max_runtime_seconds: 60
capabilities:
- name: crm.read_opportunities
access: read-only
scope: sales-team
- name: tickets.read_risks
access: read-only
scope: support-team
- name: knowledge.read_templates
access: read-only
scope: internal-knowledge
- name: llm.summarize
access: invoke
max_tokens: 1200
workflow:
- step: collect
run: [crm.read_opportunities, tickets.read_risks]
- step: validate
run: local.validate_schema
- step: summarize
run: llm.summarize
input: validated_data
- step: review
require_human_approval: true
配套的执行逻辑也可以保持简单：
from dataclasses import dataclass
from typing import Any
@dataclass
class Capability:
name: str
access: str
def run_weekly_brief(crm: Capability, tickets: Capability, summarize: Capability) -> dict[str, Any]:
if crm.access != "read-only" or tickets.access != "read-only":
raise PermissionError("Data capabilities must be read-only")
opportunities = read_crm_opportunities() # Replace with an approved connector
risks = read_ticket_risks() # Replace with an approved connector
payload = validate_and_deduplicate(opportunities, risks)
# AI is used only after deterministic collection and validation.
summary = invoke_model(summarize.name, payload, max_tokens=1200)
return {
"data": payload,
"summary": summary,
"requires_human_review": True,
}
示例中的 read_crm_opportunities、read_ticket_risks、validate_and_deduplicate 和 invoke_model 需要替换成团队现有的连接器、校验器和模型网关。重要的是执行顺序和权限边界：先获取并验证事实，再让模型表达结论，最后保留人工确认点。
采用时的工程检查表
Cloudflare OS 这类平台更适合复杂、重复、需要企业上下文的工作，而不是所有问题都交给一个通用聊天机器人。评估一个工作流时，可以检查：
- 是否能把数据访问、业务规则和模型调用拆成独立能力？
- 是否有明确的只读和写入权限？
- 模型输出是否能追溯到知识来源或连接器数据？
- 关键动作是否有人工审批、幂等控制和回滚策略？
- Token、延迟、失败重试和人工复核成本是否可观测？
- 工作软件能否被其他成员安全共享和定制？
真正值得推广的企业 AI，不是让模型参与更多步骤，而是让它在最有价值的步骤中参与。能力模型、连接器和沙箱共同提供了可控边界，工作流编排则把这些边界变成可交付的软件。采用时应从一个数据范围清楚、结果容易验收的流程开始，再逐步扩大连接器和自动化动作的权限。