Agent 架构绕来绕去，DeepSeek Harness 至少把谁干活画清楚了

Mario Zechner 在推上推荐了 DeepSeek Harness 的一篇架构文章。他说自己和 @tianyi 聊过，DSH 团队是 harness 领域少数还在做创新东西的团队之一。他提到的方向很具体：单一、长生命周期实体，ad-hoc、自由形式、可能递归的任务委派，跨系统事件摄取和触发。他提到 earendil 也在往相似方向走。

有网友把长文的核心总结成一句话：限制 Agent 生产力上限的，经常被归到模型智商上，但更直接的是人类有限的注意力带宽。人同时能追的会话数有限，模型再聪明，也要有人看结果、做判断、处理卡住的线程。

讨论里最省时间的是一张架构图。有网友把系统拆成几块：外部事件 Triggers 从 GitHub Issue、PR、CI、飞书消息进来，交给 Router 这个中央调度 Agent，它管全局上下文、判断优先级、分派任务、统一回复；Worker A/B/C 分别修 Bug、审查 PR、运行测试；最底下还有 Watchdog，独立监控、异常恢复、进度检查。

另一张图把 Router 层和 Worker 层分开，强调连续性和并行处理可以同时要。这个说法不新，但图比名词好懂：主线程保持不阻塞，具体任务丢给 worker，事件从外面持续灌进来。

评论区的问题比吹捧有用。有人问 readme 说部分功能还不在原型里，接下来是什么。有人问什么会打断正在工作的主 Agent。有人直接吐槽 token 和 cloud agents 太贵。还有人问 Firstmate 那种持久主会话加临时协作者会话怎么看。这些细节决定这套架构能不能日常用。

Giuseppe 在推上展示了一个相近的实践：构建在 Pi Durable 上，主线程当控制面板协调 threads，保持不阻塞；每个线程都是带记忆的无限聊天；可以用 @ 指定线程。视频里能看到线程还在工作、等待人回答、超时后需要重开。评论区有人说，手动复制 thread id 很痛苦，希望 t3 code 直接支持。也有人回了一句 word salad。名词确实多，但控制面和执行面分开后，痛点变得具体：中断策略、记忆持久化、成本、跨系统事件去重、权限，还有 Router 被事件淹没后怎么判优先级。

看下来，这套方向的关键不只是多开几个 Agent。Router 如果成为单点，主 Agent 的上下文和判断质量就是瓶颈；Worker 多了，观测和恢复比多开更重要。Watchdog 被单独画出来，说明大家开始承认 Agent 会挂、会卡、会超时。原文和讨论都在推上，先看图，再决定要不要读长文。

原文：https://x.com/badlogicgames/status/2116997870213906524

DeepSeek Harness 文章：https://x.com/i/article/2116829218935857152

Giuseppe 的演示：https://x.com/giuseppegurgone/status/2116232891114066092