AI 正在改变团队完成工作的方式，但真正的难点并不是接入一个聊天机器人，而是让 AI 工具进入真实工作流，同时满足权限、数据保护、审计和可靠性要求。Cloudflare OS 的思路，是把计算能力与 Zero Trust 安全能力放在同一个平台中，让团队可以更安全地重新思考工作流程，并为用户提供更完整的 AI 工具体验。
从“使用 AI”转向“重构工作流”
很多团队的 AI 落地停留在单点工具：写作工具负责生成文字，代码助手负责补全代码，内部知识库负责回答问题。这些工具可以提升个人效率，却很难形成可治理的组织能力。
Cloudflare OS 所代表的方向更接近一个工作平台：AI 任务可以运行在计算基础设施上，访问内部资源时经过统一的身份和访问控制，并且能够被纳入现有的运营体系。这样设计的价值不只是“模型能不能回答”，还包括以下问题：
- AI 任务运行在哪里，资源边界是什么？
- 哪些员工、服务或代理可以访问哪些数据？
- 敏感信息是否会被无意间发送给外部模型？
- 一次自动化操作能否被追踪、审计和撤销？
- 当模型不可用或输出不可靠时，人工如何接管？
把这些问题放在工作流设计阶段处理，AI 才能从个人工具逐步变成团队基础设施。
计算能力和 Zero Trust 要一起设计
AI 应用通常同时依赖三类能力：执行代码、调用外部或内部服务，以及访问组织数据。只提供计算能力，容易产生权限蔓延；只提供安全策略，又可能让开发者需要拼装大量基础设施。将 Compute primitives 与 Zero Trust suite 结合，可以形成更清晰的边界：
- 计算边界：通过边缘函数、服务或其他计算原语承载 AI 工作流。
- 身份边界：让用户身份、服务身份和 AI 代理身份分别可识别。
- 数据边界：按应用、用户、团队和资源类型限制访问范围。
- 操作边界：对高风险动作增加审批、日志和人工确认。
这并不意味着每个 AI 请求都需要复杂的安全流程。更实用的方式是按风险分级：普通问答可以自动执行，读取机密文档需要额外授权，修改生产配置或代表用户发送消息则需要明确审批。
一个可改造的最小工作流示例
下面的示例假设我们要构建一个“内部文档问答”服务：用户提交问题，Worker 检查身份头，然后调用一个兼容 OpenAI 风格的模型接口。示例中的身份校验和模型地址是占位实现，部署到实际环境时应替换为企业身份提供商、内部网关或 Cloudflare Access 等正式策略。
运行前准备：设置 AI_API_URL、AI_API_KEY 和 ALLOWED_EMAIL_DOMAIN 三个环境变量。将代码保存为 src/index.js，再根据所使用的 Workers 工具链部署。
export default {
async fetch(request, env) {
if (request.method !== "POST") {
return new Response("Use POST", { status: 405 });
}
const email = request.headers.get("x-user-email") || "";
const domain = email.split("@")[1];
if (!email || domain !== env.ALLOWED_EMAIL_DOMAIN) {
return Response.json({ error: "unauthorized" }, { status: 401 });
}
const body = await request.json().catch(() => null);
const question = body?.question?.trim();
if (!question || question.length > 2000) {
return Response.json({ error: "invalid question" }, { status: 400 });
}
const prompt = [
"You answer questions using only approved internal documentation.",
"If the documentation is insufficient, say that you do not know.",
`User question: ${question}`
].join("\\n");
const aiResponse = await fetch(env.AI_API_URL, {
method: "POST",
headers: {
"content-type": "application/json",
"authorization": `Bearer ${env.AI_API_KEY}`
},
body: JSON.stringify({
model: "internal-assistant",
messages: [{ role: "user", content: prompt }],
temperature: 0.2
})
});
if (!aiResponse.ok) {
return Response.json({ error: "ai service unavailable" }, { status: 502 });
}
const result = await aiResponse.json();
return Response.json({
answer: result.choices?.[0]?.message?.content || "No answer returned.",
user: email
});
}
};
请求示例：
curl -X POST "https://assistant.example.com" \\
-H "content-type: application/json" \\
-H "x-user-email: alice@example.com" \\
--data '{"question":"如何申请生产环境访问权限？"}'
在生产环境中，这段示例还应补上几个关键能力：使用经过验证的身份令牌，而不是直接信任请求头；在调用模型前检索并过滤授权范围内的文档；对提示词和输出做敏感信息检测；记录请求主体、资源范围、策略结果和模型版本；为高风险操作增加人工确认。示例的重点是展示工作流边界，而不是提供一套完整的企业身份系统。
让平台服务于真实团队
“最好的 AI 工具”不只是模型能力最强的工具。对企业用户来说，工具还必须能够融入已有权限体系，适应不同团队的工作方式，并在出错时留下足够的上下文。平台建设因此需要同时关注开发者和最终使用者：开发者需要简单的计算与部署接口，安全团队需要可执行的策略，业务团队则需要稳定、可解释、可接管的自动化流程。
采用类似 Cloudflare OS 的平台思路时，可以从一个低风险、边界清晰的工作流开始，例如内部文档检索、客服回复草稿或代码变更摘要。确认身份、数据访问、日志和人工接管机制有效后，再逐步扩大到跨系统操作和主动式代理任务。
落地检查清单
- 为每个 AI 应用定义明确的用户身份、服务身份和数据范围。
- 把 AI 执行环境与生产系统权限分开，默认采用最小权限。
- 对读取、写入、发送和删除等动作设置不同风险等级。
- 记录提示词来源、检索文档、策略判断、模型版本和最终动作。
- 为模型失败、超时、越权和异常输出设计人工接管路径。
- 从一个可衡量的工作流开始，用真实使用数据决定是否扩大范围。
Cloudflare OS 的核心启发，是把 AI 视为工作系统的一部分，而不是孤立的新工具。计算提供执行能力，Zero Trust 提供边界和控制，两者结合后，团队才有条件在保证安全与可治理性的前提下重新设计工作方式。