从 openclaw 引发的自动化热潮，到 deepchat 升级为 deepwork，企业 AI 正在从“回答问题”转向“完成工作”。这次预览版的重点，不只是换了一个产品名称，而是尝试把智能体需要的执行环境、工具和能力整合进一个可控的企业工作台。
根据目前披露的信息，deepwork 企业 AI 工作台将围绕 sandbox、shell、code、MCP 和 skill 等能力展开。它更像一个企业可控的云端智能体：模型负责理解目标和规划步骤，工作台负责提供工具、权限与运行边界。
从 deepchat 到 deepwork，变化不只是聊天体验
传统聊天产品的基本闭环是：用户提问，模型生成文本。这个模式适合知识问答、内容润色和方案讨论，但遇到真实业务任务时很快会碰到边界：
- 需要读取文件时，模型只能等待用户上传内容；
- 需要执行脚本时，用户必须手动复制命令；
- 需要调用内部系统时，往往还要额外开发一层集成；
- 需要多步处理时，过程状态、失败重试和权限审计都不清晰。
企业工作台的价值，在于把“思考”和“行动”放进同一个流程。用户可以描述一个目标，例如“分析这批销售数据，生成异常报告，并把结果整理成周报”，智能体再根据授权使用代码、Shell、文件或企业服务完成任务。
这里的关键判断标准不应只是模型答得是否流畅，而是：任务能否被拆解、工具是否可用、执行是否可追踪、失败是否可恢复，以及整个过程是否符合企业的安全边界。
五类能力如何组合成一个可执行的智能体
Sandbox：给智能体一个隔离的工作空间
Sandbox 通常用于运行临时文件、数据处理脚本或实验性代码。它让智能体可以在受限环境中完成计算，而不是直接触碰生产服务器。
企业落地时，需要明确至少几类边界：
- 文件系统是否临时化，任务结束后是否自动清理；
- 是否允许访问公网，以及允许访问哪些域名；
- CPU、内存、磁盘和运行时长上限是多少；
- 任务产物如何导出，是否需要病毒扫描或敏感信息检测。
Shell 与 Code：从建议命令到实际执行
Shell 适合调用已有工具，Code 适合处理结构化数据、生成报告或编排复杂逻辑。两者结合后，智能体不只是告诉用户“可以运行什么”，还可以在授权范围内运行并返回结果。
但执行能力越强，风险也越高。默认策略应当是最小权限：只读优先、目录隔离、网络默认关闭，高风险命令要求人工确认，并保留命令、参数、输出和操作者信息。
MCP：把企业系统接入工具层
MCP 可以被理解为连接模型与外部工具、数据源的统一方式。对于企业来说，它的意义不在于“多接几个 API”，而在于让 CRM、工单、知识库、数据平台等系统以相对一致的工具接口被智能体调用。
接入时建议把工具设计成清晰的业务动作，例如 search_ticket、get_customer、create_draft_report，而不是直接暴露一个权限过大的通用数据库接口。读操作和写操作也应分离，写操作最好支持预览、审批和幂等键。
Skill：把重复经验变成可复用流程
Skill 可以承载某类任务的提示词、输入约束、工具选择和输出格式。例如“月度经营分析”这个 Skill，可以规定先读取哪些数据、使用什么口径计算、异常如何标记、报告必须包含哪些章节。
这使企业沉淀的不只是一个模型，而是一套可复用的工作方法。Skill 仍然需要版本管理、测试样例和负责人，否则它很容易变成没人维护的隐性规则。
一个可改造的企业任务示例
下面是一个概念性配置示例，用于展示企业可以如何描述一个“销售数据分析”任务。它不是 deepwork 预览版的官方 API；实际字段和调用方式应以产品文档为准。运行前请把工具名称、文件路径和审批方式替换成你们环境中的实现。
name: weekly-sales-review
version: "0.1"
description: 分析本周销售数据并生成待审批的周报草稿
inputs:
- name: csv_path
type: string
required: true
example: /workspace/input/sales.csv
permissions:
filesystem:
read:
- /workspace/input
write:
- /workspace/output
network: deny
shell:
allow:
- python
- mkdir
deny:
- rm
- curl
- ssh
tools:
- name: python
purpose: 统计销售额、订单数和异常记录
- name: create_draft_report
purpose: 创建待审批的周报草稿
workflow:
- step: validate_input
instruction: 检查 CSV 是否包含 date, region, amount, order_id 字段
- step: analyze
instruction: 按 region 汇总 amount 和 order_id，标记销售额环比下降超过 20% 的区域
- step: export
instruction: 将分析结果写入 /workspace/output/weekly_sales.md
- step: approval
instruction: 仅创建草稿，不直接发送邮件或修改正式数据
如果要在本地快速验证“分析并生成报告”的最小逻辑，可以使用下面的 Python 脚本。它不依赖具体工作台，适合先验证任务定义和输出格式，再接入 sandbox 或 code 工具。
from pathlib import Path
import csv
from collections import defaultdict
input_file = Path("sales.csv")
output_file = Path("weekly_sales.md")
summary = defaultdict(lambda: {"amount": 0.0, "orders": 0})
with input_file.open(newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
region = row["region"].strip()
summary[region]["amount"] += float(row["amount"])
summary[region]["orders"] += 1
lines = ["# 本周销售周报草稿", "", "| 区域 | 销售额 | 订单数 |", "|---|---:|---:|"]
for region, data in sorted(summary.items()):
lines.append(f"| {region} | {data['amount']:.2f} | {data['orders']} |")
output_file.write_text("\n".join(lines) + "\n", encoding="utf-8")
print(f"report written to {output_file}")
准备 sales.csv 后即可运行：
python3 report.py
cat weekly_sales.md
在企业工作台中，这段脚本可以由智能体生成或调用，但“创建报告草稿”和“正式发送报告”应当是两个不同动作，不能因为模型完成了分析就自动获得发送权限。
真正的难点是控制面，而不是工具数量
把 Shell、代码执行和 MCP 都接入后，智能体的能力会明显增强，但企业不能只关注“能不能做”，还要设计“谁允许它做、做过什么、出了问题怎么办”。一个可落地的预览环境至少应关注以下控制项：
- 身份与权限：按用户、部门、项目和环境授予权限，避免所有智能体共享一个高权限账号。
- 人工确认：删除数据、发送外部消息、修改生产记录、创建费用或合同等动作应进入审批环节。
- 审计记录：保存任务目标、模型决策、工具调用、输入输出摘要、审批人和最终结果。
- 数据隔离：对企业文件、客户数据和源码设置租户隔离，并明确数据是否用于模型训练。
- 失败处理：工具超时、返回脏数据或重复执行时，要支持重试、回滚或转人工处理。
- 成本管理：对模型调用、代码运行时间、存储和外部 API 调用设置预算与限额。
预览版阶段尤其适合从低风险、可验证的内部任务开始，例如报表草稿、知识库检索、工单分类、代码检查和数据清洗。涉及付款、生产变更、对外承诺和大规模数据写入的任务，不宜一开始就完全自动化。
给团队的试用清单
可以用下面的顺序评估 deepwork 或类似企业 AI 工作台：
- 选一个输入稳定、结果容易验收的业务流程；
- 为任务准备少量脱敏样本和明确的成功标准；
- 先只开放读取和草稿生成权限；
- 为每一次工具调用设置日志与人工抽查；
- 记录模型节省了多少时间，以及人工返工了多少内容；
- 再决定是否扩大工具范围、数据范围和自动执行权限。
deepwork 预览版传递出的方向很清楚：企业 AI 的下一阶段不只是更会聊天，而是拥有受约束的执行环境、可组合的工具和可复用的工作技能。能否真正进入生产，最终取决于这些能力能否与权限、审计、审批和业务责任一起设计，而不是单独追求一个“更强的智能体”。