加载失败
这是一个 Show HN 帖子，介绍 Mysti——一个把多个 LLM 驱动的代理（例如 Claude Code（Anthropic）、Codex（OpenAI）、Gemini（Google））组织成“辩论→综合”流程的工具，初期以 VSCode 扩展形式出现且计划支持 CLI。讨论核心在于如何在本地/CLI 环境通过 tmux（终端复用器）、MCP 风格的中介（如 consult-llm-mcp、Pal MCP）或可移植二进制（如 gomuxai）让代理互通、共享上下文以避免重复 token 传递，并以 persona/skill 来定制代理行为。社区同时引用了多种相关项目与模式（AgentAPI、Every Code、llm-council、Autogen 等）作为实现或对照，并对成本（token 使用）、可测性（需要 benchmark）、以及许可/定价（BSL vs MIT/AGPL）提出实务性问题。总体讨论在技术集成细节、生产可用性评估和社区信任三方面集中发散。
许多评论者给出实践例子：把 Claude（Anthropic）用于快速原型、让 Codex（OpenAI）审查未提交的改动能显著提升代码质量并减少 Claude 的幻觉问题。用户描述在前端/后端任务中交替使用 Claude 与 Gemini（Google），或用“架构师”代理调用子代理构建器以分工并追踪已完成特性。实际效果包括更容易发现单模型遗漏的 bug、提高审查严谨度，以及在 tmux 窗格中并行运行代理以便人工实时干预和调试。多条评论把“开发—审查”分工和把代理作为“第二双眼”视为可复用的生产力提升模式。
实现层面的讨论集中在如何把 CLI 代理、tmux 会话和 MCP 风格的中介服务器结合：作者做了 tmux-CLI 封装，让多个代理在不同 tmux 窗格中可视化运行并通过 send-keys（带延迟）互相触发以便人工干预。虽然很多模型支持 headless/非交互模式并能流式返回 JSON，但可视化窗格便于审查与临时插手；也有人反馈子代理之间建立持续双向对话仍有困难。社区推荐或在用的配套项目包括 consult-llm-mcp（用于调用 Gemini MCP 专家）、Pal MCP server/AgentAPI 以及 gomuxai（一个可移植二进制，用于跨会话读写状态并驱动并行 tmux 会话），这些工具被用来降低上下文传递与跨代理协调的复杂度。评论还讨论把功能做成 VSCode 扩展或保持纯 CLI 两条路线，各有利弊，作者计划同时支持更多集成。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
成本和上下文传递是反复被提到的问题：把完整上下文写入子代理会显著增加 token 使用与延迟，因此作者强调共享上下文优于把上下文逐条传参。DeepMyst 团队提到未来的“smart context/自动优化”功能（如 smart-trim 和 rollover）可通过自动裁剪或抽取关键上下文将有效 token 数量降低高达约 80%，但该功能尚未完全整合到 Mysti。评论也指出缓存与 system prompt 的相互作用：改变系统指令会影响缓存命中率，从而改变成本估算。有人建议在同一模型上用不同 persona 或让 agent 的模型选择更动态以合并付费，但这些方案在 token 消耗与质量权衡上仍需验证。
社区普遍要求可复现的基准来证明多代理方法优于单一高性能模型：目前主要是零散的经验贴和小规模实验，而非系统性对照试验。部分评论引用早期观察（例如在执行流中交替调用不同模型得分更高的情况）作为初步证据，但也有人提到微软 Autogen 等早期 agent 框架在长会话中容易失稳或“崩溃”。作者表示希望社区做更多基准测试并计划在一月开展更多测评，评论者希望看到公开的可重复 benchmark、测试用例与评价指标来验证效果。与此同时，几条实战经验（如一模型开发另一个审查）仍被视为有价值的初步模式。
许可与项目可信度在评论中多次被提及：有人对 BSL（Business Source License）表示反感并要求公布定价，以评估长期可用性与企业可采纳性。作者后来在评论中说项目是免费开源并计划改为 MIT，但也有用户建议采用 AGPL 来强制衍生项目开源。此外，站点域名（deepmyst.com 与 www.deepmyst.com 未做跳转）和缺乏明确定价信息被指出为降低信任感的具体细节。总体上，社区希望在生产环境采用前看到更清晰的许可、定价与合规说明。
关于用 persona 还是 skill 定制代理行为，社区意见不一：有用户不喜欢反复调整 persona，宁愿用默认多写代码；另一些人更青睐通过具体技能（如 auto-commit）直接实现功能化需求。有人质疑 Mysti 是否只是把一个 Claude skill 换个界面；作者解释 Mysti 的关键在于“共享上下文”而不是把上下文写成子代理参数，从而减少 token 重复并避免主会话膨胀。作者还计划支持更多外部 CLI（如 Cursor、Cline）与可配置模型，以便把技能与模型选择做成可组合的插件式工作流。
也有明显的怀疑声音：把多个模型凑在一起可能只会增加非确定性与调试难度，而“专家扮演”模式在早期被热炒後也有人弃用。有人直接质问如果各个服务本身就不能正确完成任务，凑在一起如何反而产出更好结果；还有人引用 HiveMind 类似研究质疑不同模型在开放式问题上的输出是否有显著差异。这些质疑促使部分评论者呼吁更多错误分析、失败案例记录与可量化指标，而不是盲目叠加模型技术栈。
tmux: tmux（终端复用器）：在单个终端中管理多个会话/窗格的工具。评论中用于在不同窗格并行运行 CLI 代理、用 send-keys 自动发送按键并保持所有代理工作可视以便人工干预与调试。
MCP: MCP（社区语境下的中介/服务器实现）：指一类用于在本地或 CLI 环境中协调/路由到专门模型或“specialist”的协议与服务器实现，典型实现有 consult-llm-mcp 与 Pal MCP server，常用于让代理相互咨询而非重复传整段上下文。
skills / personas: skills（技能）/personas（角色）：skills 是可复用的 prompt 或功能模块（如自动提交、自动裁剪上下文），personas 是改变 system prompt 以塑造代理风格的设定。两者都用于定制代理行为，但技能偏功能化、personas 偏行为/语气层面。
token 优化（smart-trim / rollover / compact）: token 优化包括用自动化手段裁剪不相关消息、摘要或抽取关键上下文以减少传入模型的 token 数量。作者提到的 smart-trim 会用 headless agent 查找可删减的长消息，rollover 会创建新会话并注入精炼的上下文以继续任务，从而降低成本并避免频繁触达上下文窗口上限。
BSL: BSL（Business Source License）：一种对商业使用或分发有附加限制的许可模式，通常会在未来某个时间点转为更宽松许可。评论者担心 BSL 限制社区贡献与企业采用，因而建议改为 MIT 或考虑 AGPL。