Twitter AI Agent - 2026-10-05¶
1. 大家在讨论什么¶
1.1 Harness engineering 不再像“玄学”，而开始像一门可重复执行的工程实践（🡕）¶
2026-10-05 最强的一组 AI agent 话题，是把 harness 本身明确化。入选的帖子不再只是说“用更好的提示词”，而是把 agent 的工作整理成可阅读的材料，给流程步骤和组件分层命名，使其能够被分别分析和讨论。
@KirkDBorne 分享了（503 个赞，1 条回复，30,082 次浏览，879 次收藏）发布了一本 48 页的《Understanding Harness Engineering》手册，明确将这套栈定义为循环、工具接口、上下文、沙箱、验证以及长时运行任务。这之所以重要，是因为它把 harness 设计视为一个由具名部件构成、可供工程化处理的层面，而不是提示词技巧的不断堆砌。
@mattpocockuk 展示了（276 个赞，33 条回复，14,143 次浏览，189 次收藏）则把同样的思路落到了工作流层面：在默认构建流程中加入 /retro。重点不只是检查失败的运行。他明确表示，即便是一次“成功”的会话，做 retro 仍然能暴露低效之处；而一条回复进一步澄清，这一步也可以修剪不断累积的 AGENTS.md 规则，而不只是继续往里面添加更多内容。
@Lummox_eth 提出了（14 个赞，5 条回复，223 次浏览，12 次收藏）则把这种拆解进一步具体化：列出了 GPT-6 Astra 之外仍然需要的七层配套能力，包括 memory、变化上下文处理、retrieval、tools、traces 和 coordination。这一点之所以重要，是因为它把 mem0 和 MCP servers repository 这样的 GitHub 仓库视为“神经系统”的组成部分，而不是可有可无的附加项。
讨论洞察： 有价值的分歧不在于是否需要 retros，而在于一次表现良好的运行究竟还能承受多少流程，而不至于让规则文件沦为杂物堆。即便是这种反对意见，也进一步强化了主题：人们现在争论的是如何维护 harness，而不是 harness 是否存在。
与前一天相比： 相比 2026-10-04 主要是在标准化 harness 的结构，2026-10-05 则进一步转向团队可以直接复制到日常工作中的具体流程和可安装层。
1.2 扩展 agent，如今指的是 memory graph 加 manager loop，而不是造一个更大的 worker（🡕）¶
第二组话题提出了一个更强的运营层主张：多 agent 的规模化，只有在 memory 和 supervision 成为一等层面时才真正行得通。这种模式出现在 Cognition 的 Dreaming 发布中，也出现在 GrokBot 的“engineering lead”演示里，以及关于数十乃至数百个编码 agent 同时运行的具体说法中。
@cognition 介绍了（314 个赞，25 条回复，14,180 次浏览，147 次收藏）将 Dreaming 描述为一个跨会话的 memory graph，以及一套开源的“Agent Memory Repo”标准：memory 记录以文件形式存在，并通过 Git 进行版本管理。最有力的证据来自回复区：该公司表示，早期实验已经显示，多组 Devin 已经能够通过共享 memory 协同工作，而无需被明确提示这样做。
@0xRafy 报告了（51 个赞，2 条回复，5,685 次浏览，75 次收藏）展示了一个会把工作拆分给云端 agents、审查进度并让现有 agents 持续运行的 GrokBot；而 @0xCodez 放大了（55 个赞，4 条回复，4,026 次浏览，58 次收藏）则展示了同样的模式：一个由 30 多个 agent 组成的 /pstack 循环，并声称一觉醒来就能看到 20 个已落地的变更。@beamnxw 添加了（41 个赞，8 条回复，1,368 次浏览，33 次收藏）给出了最实用的操作细节：给每个 manager bot 分配自己负责的代码库区域，要求以截图和可运行的开发实例作为证明，并维护一个明确的看板，每 30 分钟把未完成的工作重新入队。
讨论洞察： 这些 agent fleet 故事里最可信的部分，不是 agent 数量本身，而是对负责区域、证明性产物和事后复盘负责人的强调。缺了这些，这些帖子读起来就像炒作；有了这些，它们听上去才像一个真正的运营模型。与前一天相比： 在 2026-10-04，manager-over-workers 模式开始显现；到 2026-10-05，这一模式通过 Dreaming 的共享记忆、按代码库区域明确划分的责任归属，以及关于在更大规模上运行 proof loops 的说法，变得更加具体。
1.3 Agent 商业仍然更看重 proof、声誉和挑战流程，而非发现（🡒）¶
偏商业方向的帖子依然以构建者为主，但它们收敛到一个一致观点：只有当审查顺序、争议权和工作历史都被明确下来时，agent 经济才有意义。保留下来的内容里，没有一条把“marketplace”本身当作最重要的界面。
@Heis_sosa 论证了（166 次点赞、47 条回复、1,932 次浏览、7 次收藏）指出，无论是 person-to-agent、agent-to-service，还是 agent-to-agent 交互，底层都需要同一条清算路径；并表示，有意义的指标不是认知度，而是有多少 agent 完成注册、接单并完成结算。@strive750 提出了（134 次点赞、137 条回复、816 次浏览）则把操作顺序说得更清楚：先交付成果，再由人工审核，然后批准付款，最后才更新永久声誉。
@0xndra 强调了（53 次点赞、51 条回复、678 次浏览）提到了 TermiX 试图把这套逻辑做成争议系统的部分：如果另一个 agent 说“prove it”，marketplace 就需要一个挑战步骤，还要有办法在不重跑整个任务、也不盲目信任任何一方的情况下验证工作结果。这是最重要的细节，因为它暴露了许多 agent 商业化叙事下缺失的一层：评估器本身也必须可被质疑。
讨论洞察： 比起口号，回复更能说明问题。Heis_sosa 的一条回复直言，真正的检验是实际使用，而不是炒作；另一条回复 0xndra 的内容则立刻追问：如果 verifier 被攻破了怎么办？这正是这个类别所需要的那种怀疑精神。
与前一天相比： 与 2026-10-04 相比，这一商业化内容簇仍处于早期阶段，但设计重心已经从抽象的结算基础设施，转向更严格的审查、批准、挑战与声誉更新顺序。
2. 什么让人感到挫败¶
Agent 技术栈仍然分散在太多标签页中，而且丢失了太多状态¶
严重程度：高。@Faazsh 记录了 用一句话概括了这个抱怨：“你的 agent stack 有 14 个标签页，却没有任何记忆。”@cognition 回答了 提出了 memory graph 和版本化记录，@Lummox_eth 回答了 则给出了一套涵盖 memory、retrieval、tools、traces 和 coordination 的 repo stack。当前的权宜之计，是自己把 sidecars 和标准拼装起来，这也正是为什么这一痛点看上去仍未被解决。值得构建：高。
监管大量 agent 仍然需要明确的 proof loops 和责任边界¶
严重程度：高。@0xRafy 想要 提到由一个 bot 负责整个 engineering loop，但更偏运营的帖子立刻展示了这意味着什么：@0xCodez 谈到了 30 多个 agents，以及 @beamnxw 明确说明了 区域责任归属、截图、转录、运行中的实例和定期任务看板审查。当前的权宜之计，是加一层 manager，再处理大量证据。值得构建：高。
Agent marketplace 在叙事与已验证使用之间仍存在信任鸿沟¶
严重程度：中高。@Heis_sosa 构建了……的框架 将结算视为关键指标，但该帖下最有力的回复认为，这个品类仍需要真实使用来验证，而不是靠炒作。@0xndra 展示了 原因在于：即便一个市场设有质疑环节，人们仍然会追问“谁来验证验证者”。目前的变通办法是在付款前加入人工审核，并配套明确的争议处理规则。值得做：竞争激烈。
3. 人们希望存在什么¶
在资金或合并权限转移前，能够对“已完成”提出质疑的验收层¶
人们反复提出的，是一种可移植的“拿出证据”界面。@strive750 描述了 一个付款前审核工作流，而 @0xndra 描述了 一个针对争议工作的质疑环节。这是一个具有立刻价值的现实需求，因为替代方案就是相信代理自行宣称任务已经完成。机会：直接。
可移植的记忆与交接控制平面¶
Dreaming、Agent Memory Repo，以及“开了 14 个标签页却毫无记忆”的抱怨，都指向同一个缺失的产品：一种能在跨会话场景下保留项目状态、又不会膨胀成巨型对话转储的机制。@cognition 提出了 一项标准，而 @Faazsh 展示了 说明了为什么团队已经在寻找运行时、记忆与管理工具的打包方案。机会：直接。
可安装的管理栈，而不是一次性的编排 hack¶
GrokBot、OpenDots、Paperclip 和 ClawLess 这些帖子都表明，用户想要的是一个他们可以安装的管理层，而不只是拿来围观。@0xRafy 推介了 “工程负责人”这一角色，而 @zer0point_eth 分享了 给出了 Dots 风格组件的开源快照，@Faazsh 分享了 则提供了可直接克隆的管理/运行时仓库。这个需求很务实，但竞争也在迅速升温。机会：竞争激烈。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪倾向 | 优势 | 局限 |
|---|---|---|---|---|
| Understanding Harness Engineering handbook | 架构指南 | (+) | 为循环、上下文、沙箱、验证和长时运行工作提供了一套共享词汇 | 只是教学材料；团队仍需把它转化为可运行的流程 |
主流程中的 /retro |
工作流技能 | (+) | 强制在运行后进行复盘，还能暴露低效环节和过时规则 | 会增加流程开销，如果机械套用还会让规则文件臃肿 |
| Dreaming / Agent Memory Repo | 记忆层 / 标准 | (+) | 提供跨会话记忆图谱，以及基于文件、带版本控制的记忆记录 | 对过时或幻觉记忆的质量仍有悬而未决的问题 |
GrokBot / /pstack 管理者模式 |
多代理编排方法 | (+/-) | 减少人工盯聊天窗口的负担，并将专业化管理者正式化 | 依赖清晰的责任边界、证据处理能力，以及很可能较充裕的使用预算 |
| 以 mem0 为中心的 “system block” 技术栈 | 组件栈 | (+) | 将记忆、检索、工具、追踪和协调明确为独立子系统 | 仍然需要用户把多个仓库组装成一个可工作的系统 |
| TermiX 的审核与质疑流程 | 结算 / 评估方法 | (+/-) | 将付款前审核和交付后质疑视为一等步骤 | 公开证据仍以推广者叙事为主，评估者信任问题也尚未解决 |
总体来看，当一种方法清晰对应某一项操作职责时，满意度最高：复查运行结果、持久存储记忆、分派专业角色，或对结果提出质疑。相比之下，保留下来的帖子对含糊的“代理平台”式说法，远没有对职责明确、界面清晰的机制那样热情。
一个明显的变通做法是分层叠加。团队会把管理者循环与记忆层配对，再加入仓库专用工具，最后补上结算或审批逻辑。这是一个可靠信号：缺失的产品边界位于基础模型之上、完整企业平台之下。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Agent Memory Repo / Dreaming | @cognition | 构建跨会话记忆图谱，并提出一种用 Git 做版本控制的记忆标准 | 代理在多次运行之间会遗忘偏好、约束和先前决策 | 记忆图谱、基于文件的记录、Git 版本控制、跨会话清理 | Alpha | 文章, 网站 |
| Paperclip | paperclipai via @Faazsh | 具备目标、预算、审批和组织架构式控制的代理管理应用 | 操作人员需要一个统一位置来监督工作，而不是在多个标签页之间来回切换 | TypeScript 应用、工作管理界面、审批、目标,预算 | 已发布 | 仓库, 文章 |
| ClawLess | 通过 @Faazsh 发布的 open-gitagent | 面向 Claw AI agents 的浏览器端、无服务器运行时 | 让团队无需配置服务器，就能在浏览器中运行 agent 工作负载 | TypeScript、WebContainers、浏览器运行时 | Beta | 仓库, 文章 |
| OpenDots | 通过 @zer0point_eth 发布的 CopilotKit | 面向持久化 agent 的开源模板，每个 agent 都有自己的机器和审批界面 | 为用户提供一套类似 Dots、始终在线的“同事”栈，并且可自行托管和扩展 | TypeScript、AG-UI、兼容 OpenAI 的模型、持久化 agent 工作区 | Beta | 仓库, 文章 |
| TermiX | TermiX 团队，由 @Heis_sosa、@strive750 和 @0xndra 讨论 | 将提案、评审、付款审批、信誉与质疑整合到同一个 agent 工作生命周期中 | agent 市场需要的是证明与争议处理逻辑，而不只是列表展示 | 提案流程、付款前评审、信誉历史、质疑环节、TEE 和 zkVM 相关声明 | Beta | clearing-path 文章, reputation 文章, challenge 文章 |
Paperclip、ClawLess 和 OpenDots 都在强化同一种构建者直觉：把缺失的操作界面做成可安装的东西。一个用于在工作场景中管理 agent，一个为 agent 提供浏览器原生运行时，另一个则把“持久化同事”的概念打包成开源模板。这种进展不同于又一个巧妙的 prompt 文件，因为它确实能够被采纳并落地测试。
Dreaming 和 TermiX 分别处在同一信任问题的两端。Dreaming 试图在不同会话之间保留内部状态，让 agent 团队的行为保持一致。TermiX 试图在不同任务之间保留外部信任，让买方能够质疑结果，并把历史记录附加到已经交付的成果上。两者合在一起，让当天最核心的模式变得非常清晰：市场正在同时围绕 agent 构建记忆与问责的基础设施。
6. 新近值得关注的内容¶
Dreaming 推出了记忆图谱，并提出了一套基于文件的 agent memory 标准草案¶
@cognition 介绍了（314 次点赞、25 条回复、14,180 次浏览、147 次收藏），在一条帖子里同时提出了产品功能和开源标准构想。这一点值得关注，因为它把 agent 的长期记忆视为一种可共享的基础原语，而不是专有的隐藏层。
/retro 把 harness 维护纳入默认流程，而不是事后清理杂务¶
@mattpocockuk 迁移（276 次点赞、33 条回复、14,143 次浏览、189 次收藏），把回顾性步骤纳入主路径，而不是留作偶尔才做的审计。这一点值得关注，因为它让 harness 质量成为持续性的工作流问题，而不再是一次性的优化项目。
超大规模 agent 的说法，只有与证明闭环配套时才显得可信¶
@0xCodez 声称 提到了 30 多个 agent，而 @beamnxw 描述 提到了一个由 200 多个 agent 组成的配置。值得注意的并不是绝对数量，而是其坚持按领域划分责任、提供截图、记录转录、进行开发实例检查，以及采用看板驱动的重试机制。
7. 机会在哪里[+++] 面向智能体工作的验收与证据层 - 来自 /retro、TermiX 的质疑步骤、先审核后付款流程，以及高度依赖证据的车队管理的迹象，都指向同一个机会：在人们信任结果之前，需要一种可复用的方式来要求“先把证据拿给我看”。¶
[+++] 可移植的记忆与交接控制平面 - Dreaming、Agent Memory Repo、mem0 风格的 system block，以及“14 个标签页，零记忆”的抱怨都表明，长期状态依然过于脆弱，也过于碎片化。
[++] 适用于多智能体工作的可安装管理器栈 - GrokBot、OpenDots、Paperclip 和 ClawLess 显示出市场对这样一层的强烈需求：它负责监督执行者、掌控预算，并提供审批机制。这个机会确实存在，但许多开源进入者已经在加速涌向这一方向。
[+] 面向智能体市场的结算与声誉基础设施 - 从 TermiX 的帖子聚焦清算、审核、声誉和质疑机制的方式中，可以看出这种需求。这个类别仍处于早期阶段，因此与其说已被验证，不如说更偏向新兴机会。
8. 要点¶
- Harness engineering 正在成为一项持续维护的运营 discipline，而不再是一次性的配置任务。 handbook、
/retro和 system-block repo 栈都在朝这个方向发展。（来源） - 记忆加管理器循环，如今已成为应对智能体规模化的默认答案。 Dreaming、GrokBot，以及 30+ 和 200+ 智能体的案例，都默认存在一个监督层和持久状态。（来源）
- 只有在证据产物和归属边界都明确时，高智能体数量的说法才显得可信。 截图、转录、开发实例和重新入队循环，比那些炫耀性的数字本身更重要。（来源）
- 智能体商业仍然围绕信任顺序运转，而不是炫目的发现界面。 先审核后付款、质疑权，以及留痕的工作历史，主导了那些真正有用的帖子。（来源）
- 最持久的构建者模式是“把缺失的那一层做成可安装的”。 Paperclip、ClawLess、OpenDots 和 Dreaming 都将一个团队真正能够采用的运营缺口打包出来。(来源)