Fable 5 & Qwen 27B – Traycer Multi-Agent Hands-On Test!

引入Traycer：开源多智能体编排新范式

本次测试的核心工具是Traycer AI推出的开源多智能体编排系统，采用MIT许可证，旨在解决大模型任务委托给小模型的平滑衔接问题。Traycer允许用户通过单一界面协调多个智能体，实现无缝的任务分发与执行。 视频中展示了该工具在实际开发中的应用场景：使用GPT-56 Soul作为主智能体，它自动将任务委派给DeepSeek V4 Flash进行代码分析，同时委派给Sonnet 5构建网站。这种架构不仅降低了成本，还提高了开发效率，体现了“Bring Your Own Agent”（BYOA）的核心理念，即用户无需购买Token，直接使用自有账户认证即可调用各类模型。

“This has some really interesting features... having bigger, more expensive models kind of delegate tasks to smaller, cheaper models, kind of like sub agents, this is something that does it very smoothly.”

核心功能解析：BYOA与智能体间通信

Traycer的BYOA功能允许用户直接接入OpenAI、Anthropic等原生API，无需经过Traycer中转，简化了授权流程。视频中演示了GPT-56 Soul和Sonnet 5均通过用户个人订阅直接运行，而DeepSeek则通过Open Code免费调用。智能体间通信（Agent-to-Agent Communication）是另一大亮点，主智能体可在同一任务窗口内创建自动化循环，让不同子智能体相互协作。例如，GPT-56 Soul不仅生成了仓库摘要，还spawn出多个子智能体，分别使用Clot Code和Open Code进行代码处理，所有操作均在单一界面内完成，极大提升了多模型协同的直观性。

“Bring your own agent... all of the authorization authentication everything is just happening through my personal subscription... makes things a lot simpler.”

跨平台支持与多模型性能对比实验

Traycer支持Mac、Ubuntu、其他Linux发行版及Windows系统，本次测试在Ubuntu环境下原生运行，展现了其对开源生态的良好兼容性。测试旨在对比顶级大模型（如GPT-56 Soul、Sonnet 5、Kimmy K3）调度本地小模型Qwen 27B时的性能差异。 实验对象为一个Arduino光线追踪渲染集群仓库，主智能体负责分析软件性能并生成网站。DeepSeek V4 Flash作为子智能体快速完成了分析A，而Kimmy K3作为子智能体则因“思考”时间较长，导致分析B耗时更久。这种设置直观展示了不同主智能体在调度本地模型时的效率差异，为后续性能数据对比奠定了基础。

实验过程与UI交互体验

在UI交互方面，Traycer采用了类似浏览器的标签页设计，用户可拖拽子智能体的输出结果作为独立标签查看。DeepSeek V4 Flash完成的分析A迅速返回结论，而Kimmy K3主导的分析B则因模型特性需要更长时间处理非平凡复杂度的Arduino仓库代码。 这种异步处理机制允许用户并行监控多个子任务的进展。视频强调，只要主智能体具备足够智能（如GPT-56 Soul或Sonnet），即可触发所有高级功能；若使用较弱的本地模型（如旧版Llama），可能会遇到兼容性问题。本次测试通过对比不同大模型对同一本地任务（Qwen 27B参与）的调度效果，揭示了主智能体的智能水平对多智能体协作效率的决定性影响。

“The UI here is really neat... I can just drag that as basically like a second tab there... this one was using Kimmy K3... this is actually a non-trivial level of complexity.”

Traycer 多智能体协作界面与资源监控

Traycer 平台的核心优势在于其能够在一个统一的界面中管理多个智能体（Agents）和标签页。除了主对话窗口，系统提供了共享的 Artifacts（工件） 功能，智能体可以将关键信息、摘要或草稿（Scratchpad）直接写入这些共享区域，便于后续查阅和整合。这些工件可以像普通标签页一样被打开、移动或重新排列，用户甚至可以将所有工件集中显示在特定的侧边栏面板中，从而保持工作区的整洁与高效。

"See and like you can manage a lot of different agents and tabs here from within this one interface."

在资源监控方面，Traycer 提供了一个类似性能监视器的 UI 组件，实时显示不同编码智能体的 API 使用限额。例如，在测试中，GPT CodeEx 的周会话使用率为 0%，这得益于订阅者近期获得的有利重置政策；而 Cloud Code 当前会话使用率为 4%。此外，界面还集成了 CPU 图标，点击后可查看系统资源（如 CPU、内存、RAM 共享率）的实时占用情况。这对于在 Ubuntu 等 Linux 系统上进行开发尤为重要，因为这类工具通常难以实现无缝集成，而 Traycer 提供了良好的可视化管理体验。

多模型对比分析与任务委派机制

在性能分析任务中，测试者同时调用了 Kimmy K3 和 DeepSeek V4 Flash 两个模型对同一代码库进行底层性能审计。结果显示，Kimmy K3 提供了更强的定量分析能力，这与其模型规模和性能优势相符。主协调智能体（Orchestrator）在对比后判定 Kimmy K3 的结果更优，这种在同一界面内直接对比不同模型输出的能力，极大地简化了模型评估流程，即便这并非测试者的最初计划。

为了进一步验证成果，测试者指示主智能体 GPT-5o-Sonnet 将性能分析中的关键结论更新到项目网站。这一过程展示了 智能体间的任务委派（Delegation） 机制：主智能体将任务分配给 Sonnet 5，后者在独立子任务中运行，负责更新网站内容。尽管测试者最初误以为 Sonnet 5 会在新子任务中直接执行，但实际流程显示，Sonnet 5 成功完成了网站更新，并返回了执行结果的超链接。

"The second audit is the stronger quantitative analysis, which definitely tracks based on model size and performance, etc."

自动化更新与多智能体协作成果

Sonnet 5 完成任务后，Traycer 系统自动更新了相关的 Artifacts，以反映最新的网站状态。测试者通过侧边栏的工件面板查看更新内容，并点击超链接在新标签页中预览网站。更新后的网站包含了之前由 Sonnet 5 基于高思考模式（High Thinking Mode）生成的内容，以及最新加入的 性能分析协调部分（Performance Analysis Reconciliation）。这部分内容整合了来自 Kimmy K3 和 DeepSeek V4 Flash 的评估结果，其中 Kimmy K3 的分析占据了较大比重。

主协调智能体在接收到 Sonnet 5 完成的消息后，自动执行收尾工作，标志着该轮多智能体协作流程的结束。最终生成的网站成为了多个智能体（GPT-5o-Sonnet、Sonnet 5、Kimmy K3 等）协同工作的结晶。这种协作模式不仅实现了代码审计与文档生成的自动化，还通过统一的界面实现了跨模型结果的整合与展示，为复杂的多步骤开发任务提供了高效的解决方案。

"This product right here or website is the culmination of multiple different Asians working together."

多智能体协作模式：Epic Mode 的架构优势

在 Fable 5 与 Qwen 27B 的多智能体测试中，Epic Mode 与 Regular Mode 的区别是理解系统架构的关键。Regular Mode 代表智能体直接执行任务，例如让 Sonnet 优化网站或让 Kimmy 进行性能分析，这种模式下智能体独立工作。相比之下，Epic Mode 是一种围绕编码智能体的结构化规划层，它不直接编码，而是作为编排者（Orchestrator）协调其他智能体。在之前的测试中，GPT-5.6 Sonnet 被启用 Epic Mode，因为它负责协调所有其他子智能体，这种分工使得复杂任务的处理更加清晰和高效。

"Epic mode is Tracer structured planning layer around the coding agent."

这种模式分离了规划与执行，使得主智能体能够专注于高层架构设计和里程碑设定，而将具体的代码实现交给专用的构建者智能体。这种架构不仅提高了代码的结构化程度，还允许主智能体在每一阶段后对子智能体的输出进行审查，从而确保最终产品的质量。对于需要复杂逻辑和多步骤实现的任务，Epic Mode 通过结构化规划显著降低了智能体在单一任务中“迷失”或产生幻觉的风险。

实验设置：Fable 5 编排本地 Qwen 2.5 27B

本次测试的核心目标是进行 A/B 测试，比较不同的编排智能体对同一底层编码模型的影响。测试环境配置如下：

测试者选择 Fable 5 作为编排者，Qwen 2.5 27B 作为本地运行的编码者。任务指令明确：Fable 5 不直接编写代码，而是作为技术顾问，分阶段指导 Qwen 27B 构建一个逼真的飞行模拟器。任务要求从飞行员视角开始，包含交互式飞行控制、详细的地面景观和仪表盘。这种设置旨在验证小参数模型在强编排智能体的指导下，能否完成复杂的全栈开发任务，同时利用本地部署降低 API 成本并提高隐私性。

第一阶段实施：静态世界与基础架构

Fable 5 采用了分阶段里程碑（Milestone-based）的策略，避免一次性将复杂任务抛给 Qwen 27B 导致其“过载”（thrash）。第一个里程碑聚焦于静态环境的搭建，具体需求包括：

1. 静态世界：天空、阳光、20公里的地面平面。
2. 跑道：标记为 3000 米长的跑道。
3. 相机：位于跑道阈值的驾驶舱高度视角。
4. 渲染循环：基础的游戏循环。
5. 仪表占位符：显示速度、高度表、航向和节流阀的 UI 元素。

"I locked it down up front and I'm giving it one milestone at a time with acceptance criteria reviewing between each."

Qwen 27B 完成了第一阶段并提交代码。Fable 5 随即启动审查流程，通过读取代码文件进行语法检查，而非直接运行浏览器（因为编排者无法直接访问浏览器环境）。审查结果显示，所有五个文件均符合声明，模块通过检查，代码结构清晰，API 使用正确，相机几何结构无误。这种严格的代码审查机制确保了基础架构的稳定性，为后续复杂的物理引擎开发奠定了坚实基础。

第二阶段规划：飞行物理与潜在风险管控

在第一阶段通过后，Fable 5 发布了第二个里程碑：飞行物理与起飞模拟。考虑到 27B 模型在自主设计空气动力学时可能出现的错误，Fable 5 采取了精确指导策略，直接规定了物理模型参数，而非让模型自由发挥：

Fable 5 在审查第一阶段时，敏锐地捕捉到了三个潜在问题：控制仅在按键事件时更新、深度缓冲精度问题以及键映射冲突。这些问题虽然未导致第一阶段失败，但为第二阶段的物理实现提供了重要的修正方向。通过这种“规划-执行-审查-修正”的闭环流程，Fable 5 有效地弥补了本地小模型在复杂逻辑推理上的不足，展示了多智能体协作在成本控制与性能优化之间的平衡优势。随着模型智能提升但成本增加，利用大模型编排小模型的策略正逐渐成为主流。

多智能体协作中的物理逻辑与指令纠错

在构建飞行模拟器的第二阶段，Fable 5 智能体为特定喷气式飞机在特定环境中分配了更为严谨的物理参数。这一决策基于一个关键判断：小型模型（Qwen 27B）可能缺乏足够的深度来处理复杂的物理交互。通过这种分工，系统能够在不依赖人工肉眼观察屏幕的情况下，验证行为的合理性。随后的里程碑包括实时仪表、驾驶舱框架、详细场景以及最终的打磨。这一阶段的核心在于利用大模型的推理能力弥补小模型在深度理解上的不足，确保物理引擎的准确性。

上下文限制突破与动态代理生成

随着项目推进，Qwen 27B 智能体在处理声音和手感等最终任务时，遭遇了131,072 的上下文长度限制。该模型在本地 Blackwell 6000 显卡上以 BF16 格式运行，虽然理论上可通过量化（Q8）扩展上下文，但 Fable 5 选择了一种更优雅的解决方案：创建一个新的子代理。Fable 判断剩余的修复工作（如 5.1 修复项）并不复杂，足以由一个拥有全新上下文窗口的新代理完成。这种机制展示了系统的容错性与自适应能力：当主协调器遇到上下文瓶颈时，可以通过分派新代理来绕过限制，同时保留主代理的上下文状态以维持整体逻辑连贯性。

"It can verify behavior without eyeballs to the screen."

本地系统故障与智能体的自主补救

在测试过程中，本地 LLM 实例出现了严重的挂起问题，特别是在处理特定文件编辑时。尽管 Fable 5 尝试通过拆分任务为四个独立的小工具调用来验证每一步，但本地系统依然不稳定。面对这种情况，Fable 5 展现了自主决策能力：它决定绕过故障的子代理，直接应用修复代码并呈现结果。这种“故障安全”机制确保了项目即使在小模型或本地环境出现问题的情况下，仍能由大型协调器推动至完成阶段。最终，Fable 5 仅修改了一两行代码，而绝大部分代码由 Qwen 27B 在 Fable 5 的指导下生成。

性能评估与飞行模拟实测

项目结束后，系统生成了详细的性能评分卡，记录了 Qwen 3.6 27B 作为构建者的表现。评估显示，Qwen 模型在“错误指令下的判断力”方面表现优异，它没有盲目遵循包含错误的指令，而是遵循了真实的仪表原理，修正了 Fable 5 预设的错误。在四轮修复中，发现了约 30 个实质性缺陷，但无一存活至最终版本。在飞行模拟实测中，速度模拟和加速度表现符合现实逻辑，这是小模型无法实现的。尽管驾驶舱模型略显粗糙，但城市景观和跑道细节尚可。然而，由于速度模拟过于真实，导致着陆尝试失败，飞机速度过快，最终仅完成了机场附近的飞越。

"It followed the real instrument principle over my parenthetical, which is exactly the judgment I wanted to keep exercising."

"Roughly 30 substantive defects were found across four fixed rounds. None survived to the final build."

多智能体协作完成飞行模拟器构建

在之前的测试中，Traycer平台利用Fable作为编排器，协调本地运行的Qwen模型完成了飞行模拟器的构建任务。虽然最终生成的模拟器在趣味性上略显平淡，但核心目标——即由Fable指导Qwen完成代码生成与逻辑实现——被成功达成。这种架构展示了多智能体系统在复杂任务分解与执行上的潜力。为了进一步探究不同模型在独立执行与协作执行下的表现差异，测试者决定进行一项对比实验，将任务完全交由本地运行的Qwen 3.6 27B模型处理，以观察其在没有外部编排指导情况下的能力边界。

Qwen 3.6 27B 独立运行测试过程与结果

测试者启动了一个新的会话，将Qwen 3.6 27B置于“史诗模式”，并修改了提示词，要求模型独立完成从开始到结束的全部任务，包括生成最终交付物。由于去除了子代理生成的指令，模型需要自行处理所有逻辑。经过长达32分钟的计算与生成时间，模型最终产出了结果。测试者随即在本地端口8080上检查了生成的应用，发现其正在运行。这一过程不仅验证了模型在长任务中的持久性，也为后续的性能对比提供了基础数据点。

独立运行与协作运行的详细对比分析

将Qwen 3.6独立运行的结果与之前Fable编排Qwen 27B的结果进行对比，呈现出显著的差异。地形生成方面，独立运行的Qwen 3.6似乎生成了更多的地形细节，但这反而导致了缺乏足够的起飞空间，不适合飞行游戏的实际游玩需求。在功能完整性上，独立版本完全缺失音效，且油门等关键控制功能无法正常工作，导致整体体验失败。相比之下，Fable编排的版本在物理引擎的 realism（真实感）上表现更佳，规划阶段包含了更精确的推力值和力学计算。这种对比突显了智能编排器在引导模型输出符合逻辑、功能完整代码方面的关键作用，而不仅仅是依赖单一模型的生成能力。

Traycer Desktop 多智能体架构的价值总结

本次测试进一步证实了Traycer Desktop 在多智能体协调方面的卓越能力。其无缝的任务分配机制和对多种智能体类型的广泛支持，极大地简化了复杂工作流的构建。特别是当用户指示一个智能体生成子代理时，系统能够自动处理这一层级关系，避免了手动配置的繁琐。这种架构不仅提升了开发效率，也为跨模型性能对比测试提供了理想环境。例如，未来可以轻松构建视频来比较Fable 5控制Qwen 27B与Opus控制Qwen 27B的效果差异。正如测试者所言：

"The way you can even just move things around seamlessly, the way it has support for so many different types of agents, it makes things really simple... it just makes things easier."

这种无缝集成与灵活编排的能力，使得Traycer成为评估和优化多智能体系统性能的强大工具，为未来的自动化开发流程提供了重要参考。