客户交付工作很少从一份干净的简报开始。客户发来PDF战略文档、数字只更新了一半的表格、遗留系统的截图、三张参考图，还有一封改需求的跟进邮件。 agency这边总得有人读完所有材料，调和矛盾，找出缺失的决策，再把这堆东西变成客户能反馈的启动摘要、交付简报、报告或跟踪表。

这第一遍处理很贵，因为它卡在策略和执行之间。太灵活了，没法用固定脚本；太重复了，又犯不着每次都让 senior 盯。agency 利润也是在这儿漏掉的：同样的接收、提取、解读、格式化、交接工作，每个客户项目都要重建一遍。

打开网易新闻 查看精彩图片

Agent 能帮上忙，但前提是工作流围绕证据来设计。那种读文件然后写个漂亮答案的通用聊天会话，风险很高。一个客户交付 Agent 应该把源材料、提取的事实、不确定的值、生成的产物、人工审批分开。这种分离，才能让 Agent 辅助的交付不至于变成每个项目的 fragile 一次性产物。

打开网易新闻 查看精彩图片

Claude Cowork 适合需要上下文、文件和外部工具的长期运行工作，用来做客户交付准备是合适的。但它不该成为 agency 存放真相的地方。对于客户工作，Agent 应该做三件事：检查混乱的源材料；产出结构化的证据和草稿产物；把不确定的决策推回给人。

agency 仍然拥有工作流规则：哪些字段重要、哪些事实需要复核、哪些模板已获批、什么发给客户、什么以后进生产代码。这个边界很重要。如果 Agent 读到简报写"计划 Q3 末发布"，输出"发布日期：2026-09-30"，看起来完成了，但事实是编造的。好的客户交付工作流会把这种不确定性保留为待解决问题。Agent 能减少第一遍工作量，但不该抹掉复核步骤。

打开网易新闻 查看精彩图片

多数 agency 从提示 Agent 开始，这搞反了。要先定义 intake 契约：Agent 允许检查哪些源材料、应该提取哪些事实、如何表达不确定性、应该生成什么产物。一个实际的客户包可能包含：PDF 项目简报、地点/产品/用户/账户/SKU 的表格、参考图或截图、描述所需交付物的短说明、现有品牌或格式约束。

intake 契约要回答：哪些源文件是权威的？哪些只是背景？哪些字段必须引用来源？哪些字段可以推断？哪些输出……