AI Know · 技术研究笔记
划重点** - Work 是异步智能体，Chat 是同步对话工具
模型架构 · Agent 框架 · 工程实践
核心原理
OpenAI 发布 ChatGPT Work 后，业界常将其误读为“加了文件附件的 Chat 加强版”。实际上，Work 与 Chat 是两种完全不同范式的产品：Chat 以“对话轮次”为基本单位，用户每次发送消息，模型立即推理并回复；而 Work 以“任务”为基本单位，用户提交一个包含目标、上下文和资源绑定的作业包，由系统在后台异步编排模型调用、工具执行和人工确认步骤，最终产出结构化交付物。
Simon Willison 在深度分析中一针见血地指出：Work 本质上是“托管式智能体运行时”，而 Chat 只是“交互窗口”。理解这一区别，是评估其能力边界和工程价值的前提。
工程实践
给开发者的三条可执行建议：
- 用 Work 处理“可验证”任务，而非开放生成。优先把合同审查、代码转换、批量数据清洗这类有明确验收条件的任务迁移到 Work；不要让它写散文或做创意策划。在任务规范中写清楚“必须包含测试命令”“输出 JSON 需通过 schema 校验”等验收标准，规划模型会据此约束执行路径。
- 将工具调用权限收敛到最小范围。虽然 Work 支持浏览器访问和代码执行，但默认应只挂载白名单工具。例如，处理内网数据库时，专门创建一个只读账号给 Work 使用；涉及写操作的任务，强制设置人工审批检查点。这样可以大幅降低越权调用风险。
- 设计幂等的任务重试机制。Work 运行在异步环境中，执行中途失败时系统会尝试重试。务必保证任务包中的每个子任务具备幂等性——例如，写入操作采用“先写临时文件，再原子重命名”模式，避免重试时出现数据重复或状态错乱。
风险边界
成本风险：Work 的计费基于总计算量（token 消耗 + 工具运行时长），而非对话轮数。一个看似简单的 10 步任务，可能内部触发数千次模型调用和数十次工具执行，账单远超预期。建议为任务设置明确的计算预算上限，并在任务告警中监测“单任务成本/工件价值”比值。
幻觉问题加剧：Chat 中的幻觉只影响单条回复；Work 中幻觉可能被后续步骤当作“已确认事实”继续推导，最终污染整个工作区，且错误链隐蔽极深。缓解策略包括：要求每一步输出必须附带来源引用，以及在每个分支节点设置“低置信度时停止并请求人工确认”。
越权调用风险：Work 具备自主行动能力，如果工具白名单设置过宽——例如允许访问内部 API 或执行 shell 命令——模型可能被诱导执行未预期的破坏性操作（如删除远程文件、修改权限）。必须严格限制工具参数可变范围，并对所有命令式操作做二次确认。
长尾输入与延迟：对于超长文档或极多文件的任务，Work 的分片策略可能导致执行时间以小时计。更棘手的是分布偏移：当输入数据分布与模型训练分布相差较远时，规划模型可能给出看似合理但执行无效的子任务序列。建议在任务开始前执行“干跑模式”，让规划模型只输出执行计划且不实际运行，供人工审核后再全速执行。