先画任务依赖，再决定要几位 Agent
虚构的社区博物馆准备一组双语展签。材料整理、中文草稿和网页检查看起来可以交给不同角色，但如果来源尚未确认，写作者再快也只会扩大错误。多 Agent 的价值来自职责、输入输出与验收清楚，而不是给聊天窗口起几个职位名称。本文保留搭团队、编排工作流、框架选型三个场景，用一次展签交付说明如何落地。 先建立单 Agent 基线：用同样材料完成一次任务，记录质量、耗时、调用与人工返工。只有任务确实可拆、边界明确且并行收益可能超过交接成本时，才增加角色。以下是原创设计与试验方案，未实际启动多个 Agent、安装框架或对外发布展签。
场景一：把角色写成输入输出契约
馆方负责人确定主题、批准材料与最终发布。协调者维护任务清单和版本，资料角色只整理指定来源，写作角色依据已确认事实写草稿，审查角色核对来源与要求。人数不必固定，一个 Agent 可以先顺序承担几步，再逐渐拆开；“CEO、设计师、执行者”这些称呼本身不赋予权限或能力。 为每项任务写输入、输出、依赖、允许工具、文件范围、完成条件与失败返回。资料角色交付事实表，列每条陈述的来源、日期与未确认项；写作者交付草稿和事实表版本；审查者交付可定位问题，不只写“整体不错”。没有证据的内容不能通过投票变成事实，多个 Agent 同意也不代表独立验证。 将可并行的工作与必须等待的工作分开。两位资料整理者可以处理不同且已指定的来源，但中文草稿必须依赖确认后的事实表，网页验收必须依赖实际页面。不要一开始让所有角色共享整段聊天与全部文件，按需提供背景；同时保留必要来源，避免摘要交接把不确定性抹掉。 独立上下文不等于安全隔离。不同角色即使有不同提示，也可能写同一个目录、共用密钥或访问同一网络。明确谁拥有文件写入权，避免两个 Agent 同时改同一产物；必要时用独立工作副本与明确合并人。文件隔离也不能自动防止外部脚本读主机资料，真实边界需按运行环境落实。 产物是角色表、任务依赖图、权限清单和可验收交付样例。人的职责是定义与审阅有判断意义的节点，不是重复批准每一个已经授权的可逆步骤。关键是哪些决定需要负责人，哪些普通处理可以继续，而不是让流程永远等确认。
场景二：把交接变成有状态的流程
为任务设状态：待输入、可执行、运行中、待审、需修订、完成或失败。每次交接包含任务编号、输入版本、产物位置、结论、未确认项与下一步。不只传一句“我做完了”，也不把聊天里的长篇解释当作可机器读取的完成条件。协调者依据产物和验收更新状态，而非依据角色的自我评价。 展签例子可以先确认事实表，再并行生成中文草稿与术语对照，汇合后审查，然后交付负责人。术语或来源冲突要回到指定责任人，不能让两个 Agent 互相争论无限循环。设最大修订轮次、耗时和成本预算，到限时交付问题清单，而不是继续调用直到看起来有答案。 保存中间状态与版本，使中断后知道哪些步骤真正完成。持久化并不自动保证外部动作只发生一次；重试前区分纯生成、文件写入和对外发布。邮件、发布、预约等副作用需要单独控制与去重，不能因为任务状态未更新就盲目重做。超时结果未知时先查实际结果，再决定重试。 质量门槛分层：格式与必填字段可自动检查，来源是否支持陈述需要核对，文化表达与最终发布由负责人判断。审查角色应能指出原文位置、错误类型与修改建议，并明确没查到的内容。审查与生成若使用同一假设，可能共同遗漏，不能把第二个模型当成天然独立审计。 展签交接说明的技术表达整理可使用 Writing Guidelines。公开详情、Vercel 固定源码与 MIT 许可已核验；它适合对已有技术流程文档做清晰表达与结构复核。它不启动 Agent 团队、不提供持久化与调度，也不负责展品事实核验。提供脱敏流程草稿与受众，仅用于交接文档这一步。 验收流程时故意加入缺失来源、审查拒绝、执行失败和重复提交样例，确认能停在正确节点并保留证据。正常路径跑通还不够，恢复路径和人工拒绝后不继续发布同样重要。产物是状态记录、交接包、审查记录、失败处理与最终验收，不是几段看起来像角色对话的文本。
场景三：用同一个任务比较框架
先列不可缺条件：运行语言、工具接入、状态与恢复、人工介入、日志、部署约束和团队维护能力，再比较候选。中文原文强调 LangGraph 与角色编排，英文还列 Microsoft Agent Framework 等候选；这些是选型对象，不是应全部安装的清单。现有脚本与顺序流程也应作为基线，复杂框架不一定更合适。 开源参考中，LangGraph 提供状态编排、持久化与人工介入相关机制；CrewAI 提供围绕角色与工作流组织协作的路线；Microsoft Agent Framework 的公开实现覆盖其支持语言中的 Agent 与工作流。具体版本、接口、许可和部署前提按当前上游核对。不能仅凭“图适合复杂、角色适合简单”就决定，更不能把框架宣传当本项目表现。 选一份同样的展签夹具，在固定环境比较：事实是否保留、错误能否定位、拒绝与中断如何处理、状态恢复后是否重复副作用、每次运行成本与人工返工如何。记录模型、工具、版本、并发与重试设置，避免把不同输入、不同预算下的结果当公平对比。没有实际测量就写试验计划，不制造速度提升数字。 给出选择与不选择理由，包括后续迁移成本、状态存储、依赖、监控与人员学习。某框架能示范一个功能，不代表团队已经能稳定维护它。先做小范围试点，保留单流程回退路径；当任务量很少、依赖很强时，选择少角色或不用新框架也合理。 本次 SkillPI 框架目录查询没有可核验的编排候选，因此不编造框架技能链接。上面的开源项目是外部技术参考，关联的写作技能仅服务文档整理。未来增加技能时再核对固定来源、许可、依赖与具体步骤，不能用名称补齐推荐卡片。
一次可执行的设计请求
“用给定合成材料设计展签协作流程，先完成单 Agent 基线计划，再列角色输入输出、依赖与权限。只让独立任务并行，设置交接版本、审查门槛、失败与最大重试。用同一夹具比较现有脚本与候选框架，不启动外部账户、不发布。交付可评审方案与实际执行记录的区别。”这类说明避免把“帮我分工”误解为无限制派生与操作。
FAQ 与排错
多开窗口算协作吗？可以由人协调，但是否有效取决于交接与责任，不是窗口数；自动编排增加的是状态与调度能力，也增加维护成本。角色越多是否越快？不一定，等待、重复上下文和审查都可能增加耗时。并行后文件冲突怎么办？明确所有权与合并步骤，不能只说“上下文隔离”。 为什么所有 Agent 都同意却仍错？它们可能共享错误来源或推测，回到证据而不是多数票。中断后能否直接重跑？先确认状态与外部动作结果，避免重复发布或写入。技能装好就会编排吗？技能可能只是方法文档，框架、运行时、工具和权限另有前提。费用与许可也分别核对，不能说所有方案免费。
来源与维护
保留原文双语的建团队、编排、框架比较与 FAQ，使用原创展签任务和失败样例。技术参考为 LangGraph、CrewAI、Microsoft Agent Framework 上游及关联写作包固定源码，移除热度、自动接管、绝对稳定与免费保证。后续按版本与目录变化刷新关联，保留公开地址和语言配对；本文不宣称已运行真实多 Agent 系统。