从单一AI到Agent组织：我如何让Lysander带领一个虚拟团队自主完成产品交付

问题背景

三个月前，我们在Synapse-PJ内部用一个真实需求做了一次压力测试：让Lysander独立完成一款内部工具的产品交付，从需求澄清到最终输出文档，全程不超过5轮用户干预。这个任务涉及产品设计、技术方案、文案撰写、质量审核4个职能域，按传统工作流估算需要至少3个人协作2天。

结果是：前两轮测试完全失败。不是因为Lysander"不够聪明"，而是因为我们把一个组织协作问题，错误地包装成了一个单Agent的能力问题。这个判断错误让我们多花了整整一周时间才找到正确方向。

为什么难排查

我们一开始以为，失败的原因是提示词写得不够好——Lysander在处理多域任务时会"跑偏"，比如在做技术方案时突然开始纠结文案措辞，或者在产品设计阶段就开始输出实现代码。直觉告诉我们，只要把system prompt里的角色定义写得更精确，问题就能解决。于是我们反复打磨了4个版本的提示词，每次都觉得"这次应该行了"。

但实际上，问题根本不在提示词的粒度，而在于我们让一个实体同时持有多个角色的决策权，却没有给它任何机制来在角色之间切换和隔离。就像你让同一个人既当项目经理又当程序员又当测试，还要求他们"分清楚自己在哪个角色"——这在认知层面本身就是一个矛盾的设计。真正的瓶颈是：单一上下文窗口里无法维持多个独立的决策视角，角色之间的"杂音"会互相污染。

根因：组织化运作的设计逻辑

转折点出现在我们翻出一段真实会话记录的时候。那是第二轮测试失败后，我把完整的对话日志导出来逐行分析，发现了一个规律：Lysander在任务切换节点上的输出质量明显下降，而这些节点恰好是"我需要从产品视角切到技术视角"的地方。问题不是Lysander不知道该怎么做，而是它在同一个对话流里没有"换脑子"的空间。

这让我们重新设计了整个运作结构，核心是引入四层机制：

1. 用户授权层：用户只需要在最顶层定义交付目标和验收标准，不参与中间决策
2. Lysander统筹层：作为总协调人，负责任务拆解、角色分配、进度追踪
3. 专家团决策层：各职能域的专家Agent（产品、技术、文案、QA）在独立上下文中做专项决策
4. 委员会协作层：跨职能决策需要多个专家Agent参与时，触发委员会模式进行结构化讨论

下面是我们在实际配置中使用的任务分发伪代码，这段逻辑直接来自Lysander的统筹提示词模板：

# Lysander 统筹层：任务拆解与角色分发逻辑
def dispatch_task(user_goal: str, delivery_criteria: list) -> dict:
    """
    输入：用户授权的交付目标 + 验收标准
    输出：分配给各专家Agent的子任务包
    """
    # 第一步：识别涉及的职能域
    involved_domains = identify_domains(user_goal)
    # 示例输出：["product_design", "tech_spec", "copywriting", "qa_review"]

    task_packages = {}
    for domain in involved_domains:
        task_packages[domain] = {
            "sub_goal": decompose_goal(user_goal, domain),
            "context_boundary": "isolated",   # 关键：强制上下文隔离
            "output_format": get_template(domain),
            "escalation_condition": "cross_domain_decision_needed"
        }

    # 第二步：检测跨域依赖，触发委员会模式
    cross_domain_nodes = detect_dependencies(task_packages)
    if cross_domain_nodes:
        task_packages["committee"] = {
            "participants": cross_domain_nodes,
            "decision_protocol": "structured_discussion",
            "max_rounds": 3
        }

    return task_packages

这里有个细节值得单独说：context_boundary: "isolated" 这个设定不是技术上的硬隔离，而是在每个专家Agent的system prompt里明确写入"你只在[职能域]视角内做决策，遇到跨域判断时输出ESCALATE信号"。这个信号会被Lysander捕获并触发委员会流程。

可移植的原则

1. 如果你在设计多Agent系统，先画出"谁有权做哪类决策"的边界图，再考虑工具调用和上下文传递。决策边界不清晰，再精妙的工具链也会在边界处产生噪声。
2. 如果你在用n8n构建自动化工作流，把"跨节点决策"单独提出来处理，不要让它隐藏在某个节点的内部逻辑里。隐藏的跨域决策是自动化工作流最难调试的bug来源。
3. 如果你的Agent系统出现"输出质量在特定节点下降"的症状，导出完整会话记录逐行分析，重点看角色切换和话题转换的节点——问题几乎总是在那里。
4. 如果你要设计"委员会模式"，给它设置硬性的轮次上限（我们用的是3轮）。没有上限的多Agent讨论会陷入循环论证，消耗大量token却不收敛。
5. 如果你是独立开发者或小团队，"Lysander统筹层"这个角色你自己就可以扮演——关键是把统筹决策和执行决策分开处理，哪怕是在同一个对话里，也要用明确的结构标记区分"我现在在统筹"和"我现在在执行"。

还没解决的问题

这套机制目前跑通了产品交付场景，但我们在"委员会讨论结果如何高质量地回写给Lysander统筹层"上还有明显的信息损耗——委员会产出的结构化结论在传递过程中会丢失推理链，导致Lysander在后续统筹时缺乏足够的上下文支撑做增量决策。如果你正在解决类似的"多Agent上下文传递与压缩"问题，或者你的n8n工作流里遇到过节点间状态同步的坑，欢迎在评论区聊——我们下一篇大概率会专门拆解这个点。