一个可交付的智能体协作空间，至少要解决这四个现场问题

做客户项目时，最常见的一句话是：“这个事情不是已经说过了吗？”

问题在于，说过不等于确认过；确认过不等于所有角色都知道；所有人知道也不等于后续动作有依赖、有责任人、有记录。

以文旅活动服务项目为例，客户方、服务商、场地方、执行团队各有一套信息。项目一多，服务商很容易陷入“群里找结论、文档找版本、电话找负责人”的状态。

本次好易haoee搭建的“文旅活动项目空间协作助手”，目标不是取代项目经理，而是把协作中最容易失控的四件事结构化。

1. 谁负责什么

不要只写角色名称，要写角色与交付物的对应关系。

客户方：确认主题、最终负责人、关键对外承诺
服务商：策划草案、宣发草案、项目复盘
场地方：可用时段、容量、设施条件核实
执行团队：现场流程、物料与执行复盘

这能避免“所有人都以为别人会处理”的项目真空。

2. 哪些信息真的确认了

智能体输出必须区分三个状态：

已确认：有明确来源和确认主体
待确认：已有议题，但没有最终结论
待补充：项目尚未提供信息

例如“场地容量”不能因为用户提到了城市文化街区，就被模型推断为某个数字。当前搭建版本中，任何未提供的日期、预算、容量、负责人、外宣文案，都会保留为待确认。

3. 下一步依赖什么

项目协作最容易出错的不是任务多，而是顺序错。

在本次案例中：

主题确认 -> 策划草案
场地条件核实 -> 日期与容量确认
策划草案 + 场地条件 -> 现场流程
日期 + 文案审核 + 负责人确认 -> 对外发布

智能体把这种依赖关系输出出来，项目负责人就能快速判断：哪些事项应该催办，哪些事项暂时不能推进。

4. 哪些动作不能由智能体做

真正能拉开交付差距的，是边界设计。

当前智能体明确不做：

• 锁定场地；
• 制定或修改预算；
• 发送通知；
• 发布售票或宣传内容；
• 修改客户系统；
• 伪造审批、负责人或项目状态；
• 删除或隐藏操作记录。

正常测试中，智能体能完成角色、材料、依赖与待确认项整理。

越界测试中，面对“直接锁场地、定预算、发布售票文案、跳过审核”的要求，智能体全部拒绝，并输出人工操作路径。这使它可以进入客户项目讨论，但不会把项目带入错误的自动化承诺。

编排与资源选择

当前使用 deepseek-v4-flash，编排为：

开始节点 -> 协作规划与工作单生成

节点先做 Planner，识别角色、材料、依赖、风险；再做 Generator，按工作单结构输出。未启用自动 Evaluator，因为预算、合同、票务、对外发布和现场安全必须由人承担责任。

本期没有接知识库、Skills、MCP Server 或长期记忆。原因是尚无经过客户确认的项目资料，也没有真实系统授权。

建议服务商后续按“模板 -> 知识 -> Skills -> 只读工具 -> 受控记忆”的顺序扩展，而不是一次性把所有能力挂上去。

对交付伙伴而言，协作空间真正能形成复利：一个客户项目做出的材料模板、确认规则、风险清单和测试集，可以成为下一个客户的交付起点。