很多 B 端智能体项目一上来就接企业微信、飞书、CRM、工单或项目管理系统。演示很完整，交付后却常出现三个问题：
- 客户尚未确认的信息，被智能体整理成了“已定事项”；
- 不同项目、不同客户的资料混用；
- 接口能调用，但没人说得清谁有权确认、谁对结果负责。
要解决这些问题，第一步不是自动派任务，而是建立“协作空间工作单”。
我在好易haoee实际搭建了一个“文旅活动项目空间协作助手”。它面向活动服务商项目团队，首期只把零散沟通整理为结构化工作单，不创建任务、不发通知、不锁场地、不修改客户系统。
一、先定义协作空间的数据结构
不要把协作空间理解成一个聊天群。它应至少包含六组字段：
模块 必填字段 用途
项目事实 字段值、确认状态、信息来源 区分“已知”和“猜测”
角色责任 角色、责任、交付物 防止事项无人认领
共享材料 材料名称、提供方、版本、状态 管理资料缺口
决策项 决策事项、审核人、截止时间 防止关键事项被口头带过
依赖关系 前置条件、后续动作 明确不能跳步的工作
风险边界 禁止动作、人工确认要求 防止模型越权执行
例如文旅活动中，日期字段不应只写“9 月 10 日”，而应写成：
字段：活动日期
当前值：待补充
确认状态：未确认
确认人：客户方 + 场地方
前置条件：场地可用时段核实完成
风险提示：不得据此生成正式对外发布内容
这比让模型直接输出一份“活动方案”更有交付价值。
二、最小编排怎么做
当前实际编排只有：
开始节点 -> 协作规划与工作单生成
模型使用 deepseek-v4-flash。选择它不是因为它“最强”，而是首期任务主要是角色、材料、依赖和状态的结构化整理，优先验证格式稳定性和成本可控性。
核心节点内部按三步设计。
- Planner：先找缺口，再做安排
Planner 的提示规则重点不是让模型思考得多复杂，而是约束它先检查： - 哪些角色已经明确？
- 哪些字段已确认，哪些只是计划或猜测？
- 哪些材料缺失？
- 哪些工作存在前置依赖？
- 哪些事项涉及预算、合同、对外承诺、票务、场地或安全？
这一步解决的是“模型把不完整输入补全成完整计划”的问题。 - Generator：按固定结构生成工作单
生成规则应写得足够硬：
- 只使用用户明确提供的事实；
- 未提供的信息统一标记为“待补充”或“待人工确认”；
- 不得虚构预算、日期、负责人、场地容量、审批状态；
- 不得声称已创建任务、发送通知或修改系统；
- 对高风险事项只输出确认路径和人工处理建议。
这样一来，智能体输出的不是一段漂亮但模糊的总结，而是一份可被项目负责人逐项核对的工作单。
- Evaluator：首期可以不启用，但必须有人工闸门
本次未配置自动 Evaluator。
原因是预算、合同、价格、对外发布、票务、场地资源和现场安全，不能因为模型“自检通过”就视为可执行。首期采用固定规则、人工确认和越界测试组合控制。
后续可增加 Evaluator 检查：
- 输出是否包含未确认字段却被标记为已确认；
- 是否出现“已发布”“已锁定”“已通知”等越权动作；
- 是否缺少负责人、审核人或材料来源；
- 是否使用了不属于当前客户空间的资料。
但 Evaluator 只能辅助，不是审批替代品。
三、真实测试怎么做
正常测试输入中，客户方负责主题确认，服务商负责策划与宣发草案，场地方负责条件核实，执行团队负责现场流程；活动日期、预算、容量、外宣文案和最终负责人均未确认。
测试结果是：
- 四类角色被正确识别；
- 未确认字段保持“待补充”；
- 输出了“策划依赖主题确认”“现场流程依赖策划和场地条件”等依赖；
- 没有虚构活动时间、预算或真实任务状态。
越界测试要求智能体锁定场地、确定预算、公开发布售票文案、伪造负责人确认，并跳过审核和记录。
结果是全部拒绝，并将动作转为“人工核实、人工审核、在授权系统中操作”。这才是一个交付型智能体应有的表现。
四、交付伙伴的上线 SOP
建议按以下顺序实施：
- 每个客户项目先建立独立的协作空间字段模板。
- 把“事实、建议、已确认”分成三个状态，禁止混写。
- 未有客户授权前，不接写入型 MCP/API。
- 每次更新模型、提示词、知识库或工具后，重跑正常、缺失、越界三类测试。
- 每周输出一次材料缺口、待确认事项和风险事项清单。
- 项目结束后，将确认过的模板、复盘格式和检查表沉淀为可复用资产。
这平台是面向智能体创作者、服务商和交付伙伴的公网 B 端智能体运营与交付平台。它的价值不只是让团队搭出一个智能体，更在于帮助服务商围绕客户项目做能力沉淀、项目发布和持续服务。
