Twitter AI Agent - 2026-06-02¶
1. 人们在讨论什么¶
1.1 context、memory 和 harness 成了 Agent 构建者的共同语言 🡕¶
当天讨论最热的并不是哪个模型赢了基准测试，而是如何把 Agent 工作拆分为 context、memory 和 harness 三层，以及判断其中哪些层能在生产环境中真正形成复利。四条入选内容支撑了这一主题。
@DataChaz 认为（230 个点赞、21 条回复、30,013 次浏览、348 次收藏）认为，真正能长期积累的能力包括 context engineering、工具设计、orchestrator-subagent 模式、严格的评测纪律、作为协议层的 MCP，以及“harness > model”的思维方式。最有价值的回复马上把这个观点往前推进了一步：有人说，如果 Agent 无法从崩溃的子进程中恢复，或无法续接会话，那么 harness 比 MCP 更重要；还有人说，harness 需要具备审计轨迹。
@nabu_lines 写道（72 个点赞、46 条回复、2,008 次浏览）认为，构建者在沉迷排行榜频繁更替之前，应该先学会 context engineering、memory engineering 和 harness engineering。在后续回复中，他将 context engineering 定义为信号选择；将 memory engineering 定义为 Agent 随时间记住什么、遗忘什么、检索什么；将 harness engineering 定义为围绕模型构建的工具、工作流、编排、代码和系统设计。
@mfpiccolo 写道（58 个点赞、5 条回复、13,319 次浏览、115 次收藏）认为，当工作单元是整个框架时，harness 臃肿就是一种结构性问题。他给出的修复方案是使用更小、可替换的 worker 和类型化函数，让检索、重排序和 provider 调用可以彼此独立替换，而不是不断把一个单体系统越堆越大。
讨论洞察： 回复不断把“harness > model”具体化为一组更明确的要求：崩溃恢复、会话续接、事件追踪，以及可审计的历史记录。
与前一天对比： 6 月 1 日的讨论把上下文处理视为生产瓶颈。到 6 月 2 日，这个问题有了更稳定的词汇框架，讨论也开始转向更小、更容易替换的组件。
1.2 多 Agent 架构图开始收敛到控制平面、验证循环和 memory manager 🡕¶
随着这套词汇逐渐稳定，人们分享的架构图也越来越相似：顶部是编排层，中间是专用 worker，底部是工具和 memory，外面再包一层验证或可观测性。四条入选内容支撑了这一主题。
@MeenakshiYACS 分享了（83 个点赞、29 条回复、784 次浏览）分享了一套参考架构：在一张图里同时列出了用户与客户端入口、编排与控制平面、专用 Agent、工具、memory、监控、可靠性，以及治理或安全模块。它的核心判断与当天更广泛的讨论一致：Agent 本身不是系统，围绕 Agent 搭建的架构才是系统。
@adxtyahq 认为（68 个点赞、8 条回复、1,440 次浏览、50 次收藏）认为，多 Agent 系统最难的部分，已经不再是让一个 LLM 回答问题，而是让编排、评测、路由、验证循环和 memory 在生产环境中可靠运行。随附的工作流图把这一点具体化，展示了 planner、researcher、retrieval、analysis、validator、critic、response 和 memory-manager 等角色。
即便是一条互动不高的推广帖，@DataScienceDojo 展示了（3 个点赞、488 次浏览）也呈现出同样的生产模式：由 supervisor agent 拆解任务，分发给并行的专业 agent，最后把合并结果交给 synthesis 步骤，而不是依赖单个通用 agent。
@hnshah 总结道（19 个点赞、9 条回复、4,732 次浏览、57 次收藏）把工作流的变化概括为“想法变成计划”“计划变成持久化上下文”“Agent 并行运行”，而人的角色则更接近判断。回复进一步点明了运营层面的注意事项：竞态条件、更安全的计划或审查轨迹，以及多 Agent 同时运行时对持久化工件的需求。
讨论洞察： 最有价值的回复并不太在意“多 Agent”这个标签本身，而更关心当专业 worker 共享状态时，如何协调、验证，以及在出错后如何恢复。
与前一天对比： 6 月 1 日更强调 harness 组件和安全运行时。到 6 月 2 日，传播开来的已经是完整的全栈架构图和按角色划分的循环，看起来更接近可复用的操作模型。
1.3 GitHub 和 Microsoft 正把 Agent 推进受治理的生产界面 🡕¶
最具体的平台动作来自 GitHub 和 Microsoft，而这两次发布都呼应了时间线中已经出现的运营者抱怨：阻碍生产落地的，与其说是模型质量，不如说是信任不足和上下文缺失。四条入选内容支撑了这一主题。
@joaomdmoura 表示（36 个点赞、6 条回复、9,976 次浏览）认为，大多数 Agent 项目之所以 ROI 转负，并不是因为 Agent 失效，而是因为它们根本进不了生产环境。他说自己的团队经常跑的是 GPT-4o mini，真正的障碍是治理、可控的数据暴露范围，以及缺失的可观测性；Sam Charrington 在回复中补充说，如今仅靠测试已经不够，决定系统是否值得信任的是 guardrails、red-teaming、可观测性，以及合适的人类参与环路。
@GHchangelog 宣布（4 个点赞、516 次浏览、5 次收藏）提到了 GitHub Agent Apps。链接的更新日志显示，合作伙伴 agent 现在可以从 GitHub Marketplace 安装，并可通过分配 issue、在 PR 评论里 @ 提及 agent，或在 Agents UI 中选择 agent 来调用。这意味着 agent 成了 GitHub 原生工作流界面的一部分，而不再只是旁路集成。
@GHchangelog 宣布（3 个点赞、179 次浏览、3 次收藏）表示，Copilot code review 现在支持可定制的 agent skills 和 MCP 连接，并为更复杂的 pull request 新增了 Medium 分析层级。链接的更新日志称，审查现在可以从 issue tracker、文档、服务目录和事故处理工具中拉取上下文，而共享配置会把这些设置同时带到审查和 cloud-agent 工作流中。
@Microsoft365Dev 宣布（7 个点赞、340 次浏览）把 Work IQ 称为“面向每个 Agent 的生产级智能”。Microsoft 的 devblog 将其描述为一个 agent-first 层，覆盖聊天、上下文、工具和工作区，并提供 A2A、远程 MCP、REST 端点、基于 Rego 的策略引擎，以及内置日志和可审计能力。
讨论洞察： 这些发布虽然路径略有不同，但都在解决同一个抱怨：给 agent 提供组织上下文，收窄工具暴露面，加上策略与日志，并让管理员能够控制成本和信任。
与前一天对比： 6 月 1 日还把运行时安全视为 Agent 周边正在形成的一层；到 6 月 2 日，GitHub 和 Microsoft 已经把这一层打包进了主流开发者工作流。
1.4 skills 正变成带有分发和反馈循环的可安装资产 🡕¶
关于 skills 的讨论，已经从“把 prompt 存到某个地方”转向仓库、安装器、市场和评测循环。四条入选内容支撑了这一主题。
@GithubProjects 强调了（13 个点赞、1 条回复、1,643 次浏览、17 次收藏）介绍了 Matt Pocock 的公开 skills 仓库，里面是一组面向真实工程工作的轻量、可组合 skills。该仓库和 skills.sh 页面确认可通过 npx skills@latest add mattpocock/skills 安装，并提供围绕 grilling sessions、共享语言文档、TDD、诊断和架构清理的目录，而不是用一个庞大的流程包装器包办一切。
@justinwetch 介绍了（16 个点赞、5 条回复、15,223 次浏览）介绍了 Skill RSI，这是一套用于递归改进 agent skills 的本地系统。仓库描述了本体构建、champion-vs-challenger 实验、prompt 级证据，以及只有在评测中获胜时才会晋升的机制；一条回复立刻点出了真正的难点：在没有明确答案键的模糊领域里，评分该怎么做？
@github_skydoves 发布了（4 个点赞、200 次浏览）介绍了 Play Billing Skills；仓库内容支持这一说法，提供了 45 个面向任务的 skills，覆盖 Google Play Billing 和 RevenueCat Android 流程中的 RTDN、续订、套餐变更、webhook 等生产环境边缘场景。
@windsurf 表示（18 个点赞、4 条回复、1,474 次浏览）表示，Codex CLI 现在可以在 Devin Desktop 中运行。链接的 ACP 文档介绍了一种 coding agent 与编辑器之间的开放协议，它也可以在同一界面承载 Claude Agent、OpenCode、Junie、Gemini CLI 和自定义 agent。这让分发不再只是仓库问题，也成了互操作性问题。
讨论洞察： 新的工作不只是编写 skills，还包括在多个 agent 和运行时之间对其进行打包、安装、路由、版本管理和评测。
与前一天对比： 6 月 1 日聚焦 skills hub 和托管式 registry；到 6 月 2 日，讨论里已经出现了安装命令、GitHub 仓库，以及专门用于改进 skills 本身的明确循环。
2. 什么让人沮丧¶
生产信任和可观测性仍然挡住了本来能工作的 Agent¶
严重程度：高。@joaomdmoura 表示（36 个点赞、6 条回复、9,976 次浏览）认为，大多数 Agent 项目 ROI 变负，并不是因为模型失效，而是因为组织不会把自己不信任的系统推上线。他举的例子很具体：无法满足的治理要求、无法控制的数据暴露，以及缺失的可观测性层。回复没有缓和这个抱怨，反而把它说得更尖锐：Sam Charrington 表示，如今测试是必要条件，但远远不够；真正带来部署信心的是 guardrails、red-teaming、可观测性，以及 human-in-the-loop 设计。@DataChaz 认为（230 个点赞、21 条回复、30,013 次浏览、348 次收藏）下也有人回复称，如果 Agent 连崩溃子进程恢复或会话续接都做不到，技术栈其他部分几乎都不重要。人们当前的应对方式，是把上下文和控制能力推入 MCP 界面、策略引擎、审计日志，以及 GitHub code review 和 Work IQ 之类的审查工作流。这个方向值得投入，因为大型平台已经在围绕同样的痛点发布产品。
框架臃肿和协作开销让多 Agent 系统变得脆弱¶
严重程度：高。@mfpiccolo 写道（58 个点赞、5 条回复、13,319 次浏览、115 次收藏）认为，harness 团队会陷入一种可预测的漂移循环：框架长出本不需要的功能，system prompt 越来越大，检索层翻倍，每个任务的成本最终涨到三倍。@adxtyahq 表示（68 个点赞、8 条回复、1,440 次浏览、50 次收藏）认为，真正的挑战是让多个 agent、工具和工作流可靠协同，而其回复则抱怨协作、实时状态共享，以及 subagent 遗忘上下文的问题。@hnshah 总结道（19 个点赞、9 条回复、4,732 次浏览、57 次收藏）谈到了并行 agent 的好处，但马上就有人追问竞态条件。大家的应对模式很一致：更小的 worker、类型化函数、checkpoint 恢复、计划或审查轨迹，以及更严格的验证循环。这个方向值得投入，因为这些失败最终会表现为成本上升、协作 bug，以及长时任务不可靠。
memory 依然太容易被重置¶
严重程度：中高。@nabu_lines 表示（72 个点赞、46 条回复、2,008 次浏览）认为，memory engineering 已经成了一门独立学科，并在回复中将其定义为决定 Agent 随时间记住什么、遗忘什么、检索什么、学习什么。@adxtyahq 表示（68 个点赞、8 条回复、1,440 次浏览、50 次收藏）下面，有构建者问该如何防止 subagent 忘记上下文，并在几轮迭代后变得越来越不可靠。@KaiteeShiks 表示（50 个点赞、4 条回复、1,994 次浏览）认为，很多 Agent 会“忘掉一切”，包括此前的决策、项目上下文、用户偏好和过去的互动；链接的 Memanto 仓库则试图通过 remember、recall 和 answer 让 memory 成为可查询的能力，不过该帖子本身被标记为 #ad。人们的应对方式包括：在工作流中明确设置 memory-manager 角色、保留持久化笔记，以及使用旁路 memory 工具，而不是假设基础 Agent 会自己记住一切。这个方向值得投入，因为 memory 丢失会直接浪费重复劳动，并破坏长会话稳定性。
Agent 商业仍然缺少可移植的信任¶
严重程度：中。@tetsuoai 表示（85 个点赞、11 条回复、3,422 次浏览、23 次收藏）称其 Solana marketplace 上线了 10 个新工作，并告诉用户去完成任务、通过审核、拿到报酬；但马上就有人追问，究竟由谁来判定工作是否真的完成：买家，还是平台的测试、审核和争议处理系统？@aashatwt 构建了（47 个点赞、12 条回复、1,835 次浏览）介绍了带 verified enclaves 且没有 human in the loop 的 AgentLance，但最有力的回复指出，跨 marketplace 的声誉可移植性仍未解决。@allscaleio 表示（43 个点赞、11 条回复、2,187 次浏览）称其 portable checkout skill 消除了支付基础设施工作，但回复仍在追问最基本的信任问题，例如默认由谁控制密钥。人们目前依靠人工审核、verified enclaves 和 portable checkout skills 来应对，但信任层依然是碎片化的。这个方向值得投入，因为支付和任务轨道已经存在，而验证、声誉和争议处理还不能在不同市场之间顺畅迁移。
3. 人们希望出现什么¶
带凭证、可恢复的持久化上下文¶
最明确的需求不是更大的上下文窗口，而是能在崩溃后继续存在、带有来源信息、并且事后可检查的上下文。@DataChaz 下面的回复要求崩溃恢复、会话续接和审计轨迹；@hnshah 下面的回复认为，计划和审查工件才是让人类能够安全扩展并行 agent 的关键；而 @joaomdmoura 则表示，可观测性才是让 Agent 值得部署的信任基础。GitHub code review 的 MCP 支持和 Microsoft Work IQ 部分回应了这一需求，但二者都绑定在特定平台上。机会：直接。
无需手工搭检索管线的共享企业上下文¶
GitHub 的代码审查更新和 Work IQ 的公开预览材料之所以存在，是因为团队希望 Agent 能访问 issue tracker、文档、服务目录、邮件、会议、文件、聊天以及其他组织信号，而不用再手工搭一层检索系统。这种需求是务实且紧迫的，不是愿景式的：当前的替代方案仍是平台专属的 MCP 接线、插件配置，或定制 glue code。这些产品证明了需求存在，但还没有提供覆盖技术栈其余部分的通用上下文层。机会：直接且竞争激烈。
可在任何地方安装，并且能证明自己确实变好的可移植 skills¶
Matt Pocock 的 skills 仓库、Skill RSI、Play Billing Skills 和 ACP 都指向同一个诉求：把 skills 当成可移植资产，而不是静态 prompt 片段。构建者想要的是安装流程、跨 agent 兼容性、领域化工作流，以及能够证明新版本 skill 真的优于旧版本的证据。眼下这些部件是分散存在的——仓库、安装器、协议和评测循环——但还没有一个占主导地位的跨 agent 打包与评分层。机会：直接。
面向 agent-to-agent 工作的可移植信任与声誉¶
商业相关讨论里最有分量的回复，并不是要求更多 marketplace，而是在追问：Agent 怎么知道上次到底是谁交付了结果，谁来决定工作已经完成，以及争议如何跨市场解决。@aashatwt 立刻收到回复称，声誉可移植性仍未解决；@tetsuoai 引来了关于验证的提问；@allscaleio 则显示，portable checkout skills 可以先解决支付流程，却还没解决信任流程。这是一个现实需求，但仍处在早期，而且竞争会非常激烈。机会：直接且竞争激烈。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Context / memory / harness engineering | 方法 | (+) | 为构建者提供一套共享词汇，用来区分信号选择、持久化和编排工作 | 仍需配套具体的恢复、来源追踪和审计机制，才能在生产环境中真正产生价值 |
| 多 Agent 工作流模式 | 方法 | (+/-) | planner、specialist、validator、critic 和 memory-manager 这些角色让职责更清晰 | 协作开销、竞态条件和上下文漂移依然常见 |
| GitHub Agent Apps | 平台 | (+) | 可将合作伙伴 agent 直接安装到 issue、PR 评论和 Agents UI 中 | 第一波仅限合作伙伴，且受管理员权限控制 |
| Copilot code review skills + MCP | 审查 / 治理 | (+) | 将组织上下文引入审查，并为复杂变更增加更深入的 Medium 层级 | 仍处于公开预览阶段、积分成本更高，而且默认假设 GitHub 专属工作流 |
| Work IQ | 企业智能 / MCP | (+) | 在一个 agent-first 层里统一聊天、上下文、工具、工作区、策略和日志 | 需要 Microsoft 租户权限、管理员同意和企业级推进工作 |
| ACP | 协议 | (+) | 让同一个桌面界面承载 Codex CLI、Claude Agent、OpenCode、Gemini CLI 和自定义 agent | 认证、计费和 registry 配置仍分别归各个 agent 自己处理 |
| mattpocock/skills | Skill 仓库 | (+) | 小而可组合的 skills，加上 grilling 和共享语言文档等对齐工作流 | 依赖团队有纪律地采用，并需要逐仓库配置 |
| Skill RSI | Skill 评测 / 改进 | (+) | 把 skill 更新当作带本体和 prompt 级证据的受控实验 | 仍处早期阶段，在答案标准不清晰的模糊领域尤其难用 |
| Play Billing Skills | 领域技能仓库 | (+) | 把生产计费中的边缘场景编码为 agent 可用的工作流和安装脚本 | 范围仅限 Android、Google Play 和 RevenueCat |
| MEMANTO | Memory 工具 | (+/-) | 把 memory 定位为可查询的旁路组件，并提供 remember、recall 和 answer 原语 |
当前数据集里的社会证明部分带有赞助性质，而且又增加了一层服务边界 |
总体来看，人们更偏好那些要么缩小工作单元、要么集中治理能力的工具。迁移路径很清楚：从 prompt 文件夹走向可安装的 skills 和协议，从单体 harness 走向 planner 与 validator 循环，从盲目往上下文里塞内容走向 MCP 和 Work IQ 这样的共享上下文层。竞争格局也很明确：GitHub 和 Microsoft 正在把信任与上下文打包进大型平台，而基于仓库的 skills 与 ACP 则在反方向上推动可移植性。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Co-Scientist | Google DeepMind | 生成、辩论并演化科学假设的多 Agent 研究伙伴 | 假设生成是现代科研中的瓶颈 | Gemini multi-agent coalition、web search、ChEMBL、UniProt、实验性 AlphaFold 用法 | Beta | 推文、博客、工具 |
| Work IQ | Microsoft | 面向 Agent 的智能层与 Microsoft 365 工作流插件市场 | 企业 Agent 需要受治理的上下文、工具和工作区 | A2A、远程 MCP、REST、Rego policy engine、SharePoint Embedded 工作区 | Beta | 推文、开发博客、仓库 |
| GitHub Agent Apps | GitHub + 首批合作伙伴 | 可直接参与 GitHub issue 和 pull request 的可安装 agents | 第三方 agent 需要在开发者工作流中拥有原生位置 | GitHub Marketplace、GitHub Apps、Copilot、Actions integration | 已发布 | 推文、更新日志 |
| Skills | Matt Pocock | 面向 coding agents 的可组合工程技能库 | AI 辅助开发中的失配、冗长和架构漂移 | Markdown skills、skills.sh、CONTEXT.md、ADR、issue-tracker 配置 |
已发布 | 推文、仓库、skills.sh |
| Skill RSI | Justin Wetch | 通过受控实验改进 agent skills 的本地系统 | 团队缺少一种可重复的方法来判断新版本 skill 是否真的更好 | 本地 UI、Codex plugin、本体、champion-vs-challenger 评测循环 | Beta | 推文、仓库 |
| Play Billing Skills | RevenueCat | 45 个可供 agent 使用的 Android 计费配方 | 生产环境中的计费集成边缘场景太多，通用 prompt 难以覆盖 | Markdown skills、安装脚本、Google Play Billing、RevenueCat Android SDK | 已发布 | 推文、仓库 |
| AllScale Checkout | @allscaleio | 面向自主商业的可移植 checkout skill | 对大多数 agent 来说，支付流程集成仍然过于定制化 | ERC-8183 skill、自托管稳定币结算、checkout 与 webhook 工作流 | 已发布 | 推文 |
| AgentLance | @aashatwt | 一个 marketplace：由 CEO agent 拆解工作，专业 agents 从 verified enclaves 中竞标 | agent-to-agent 签约仍缺少执行信任与协作机制 | EigenCloud verified enclaves | Alpha | 推文 |
| AgenC Marketplace | @tetsuoai / @tetsuoarena | 一个任务 marketplace：agent 领取工作、通过审核、获得报酬 | agent 工作需要实时需求、审核和结算闭环 | Solana marketplace、审核门槛、钱包结算 | Beta | 职位、发布 |
Co-Scientist 之所以格外突出，是因为它不只是一个预告帖。DeepMind 的官方文章描述了一个由 supervisor 和 generation、reflection、ranking、evolution、meta-review 等专业 agent 组成的系统，并把它和肝纤维化、ALS 以及衰老研究中的公开案例联系起来。这使它成为当天最清晰的案例：一个专门化多 Agent 系统已经与现实世界合作者相连，而不只是停留在泛泛的构建者话术上。
Work IQ 和 GitHub Agent Apps 则从两家不同的既有平台方那里，展示了同一种平台化趋势。Microsoft 正把受治理的上下文和工具做成企业智能层；GitHub 则把第三方 agent 变成可安装的工作流参与者。GitHub 另外推出的代码审查 skills 和 MCP 功能，也暗示这些界面会继续收敛。
skills 相关项目则体现了第二种、规模更小的构建模式：窄而深的专业能力，正被打包成可安装资产，而不是被吞进更大的框架。Matt Pocock 的仓库聚焦对齐和共享语言，Skill RSI 增加了受控实验，而 Play Billing Skills 则把一个尤其容易出错的领域做成了可复用目录。
AllScale Checkout、AgentLance 和 AgenC 展示了商业模块的拆分：checkout skills、签约市场，以及先审核后付款的闭环。需要注意的是，回复整体仍然持怀疑态度：执行轨道已经存在，但声誉可移植性和验证层仍未完成。
6. 新动态与值得关注的内容¶
Co-Scientist 把多 Agent 论点变成了公开的科学产品¶
@GoogleDeepMind 介绍了（300 个点赞、23 条回复、16,047 次浏览、90 次收藏）介绍了 Co-Scientist：一个基于 Gemini 的多 Agent 系统，能够生成、辩论并演化假设。链接的 DeepMind 文章详细解释了这套 agent coalition——generation、proximity、reflection、ranking、evolution、meta-review 和 supervisor 等角色——并将其与公开合作者和纤维化、ALS、衰老研究中的已发表案例联系起来。值得注意的转变在于，多 Agent 模式在这里以严肃科研产品的形式出现，并且有公开证据支撑，而不只是构建者式表演。
ACP 让“自带 Agent”成为有文档支持的桌面工作流¶
@windsurf 表示（18 个点赞、4 条回复、1,474 次浏览）表示，Codex CLI 现在可以在 Devin Desktop 中运行。链接的 ACP 文档将 Agent Client Protocol 描述为一种类似 LSP 的 coding agent 标准，并明确列出 Codex CLI、Claude Agent、OpenCode、Junie、Gemini CLI 和自定义 agent 为兼容对象。这一点很重要，因为互操作性正开始从演示走向有文档支撑的产品行为。
portable checkout 成了一种 skill，而不再是集成项目¶
@allscaleio 表示（43 个点赞、11 条回复、2,187 次浏览）表示，AllScale Checkout 已作为 BitAgent marketplace 上的 portable skill 上线。被引用的公告把这种新意具体化了：凭证设置、服务端签名、checkout intent 创建、支付状态轮询、webhook 验证和调试，都被打包成一个可复用的 skill 包，而不是又一个定制集成项目。这很值得关注，因为它表明支付工作流正开始变成可以在不同 agent 之间迁移的 skill 对象。
7. 机会在哪里¶
**+++］ 受治理的上下文与可观测性层**——最有力的证据簇来自［@joaomdmoura、GitHub 代码审查 MCP 发布、GitHub Agent Apps 和 Microsoft Work IQ。尚未被满足的需求并不是另一个更聪明的模型，而是一种让 Agent 获得组织上下文、策略、日志和可控信任、从而真正能够上线的方式。
[+++] 可移植的 skills 打包与评测 —— Matt Pocock 的 skills 仓库、Skill RSI、Play Billing Skills、ACP，以及 GitHub 新推出的 skills 界面，都指向同一个切口：skills 需要分发、安装流程、互操作性和有证据支撑的版本管理。现在市场上已经有仓库、协议和实验，但还没有一个占主导地位的层把它们真正连接起来。
[++] 更小的 harness 组件与协作工具 —— DataChaz 的框架、mfpiccolo 对框架臃肿的批评、adxtyahq 的工作流帖子，以及 hnshah 围绕持久化计划的讨论，都在说明编排单元应该更小。机会在于构建工具，让 subagent 更容易协调、恢复、检查和替换，而不至于把整个 harness 做成一座难以撼动的纪念碑。
[++] 带来源信息的可查询 Agent memory —— nabu_lines 对 memory engineering 的表述、adxtyahq 关于上下文漂移的回复串、Memanto 的旁路 memory 方案，以及当天反复出现的架构图，都指向同一个缺口：Agent 需要的是类型明确、可检查、可恢复的 memory，而不是简单塞进一大团上下文。
[+] 面向 Agent 商业的可移植信任与声誉 —— AllScale Checkout、AgentLance 和 AgenC 说明支付、enclave 和任务闭环开始能跑起来了。尚未解决的是可移植的声誉、验证和争议处理层，这也是为什么回复不断追问，到底由谁来判定 Agent 的工作已经完成。
8. 要点¶
- 讨论正在收敛为三层结构：context、memory 和 harness。 DataChaz 和 nabu_lines 都把持久优势放在这三层，而不是基准榜单的涨跌上；回复则进一步补上了崩溃恢复和审计轨迹，认为这才是成熟度的真正门槛。（来源）
- 多 Agent 的可信度，如今取决于编排和验证，而不只是更多 Agent。 Meenakshi 的架构图、adxtyahq 的工作流、DataScienceDojo 的 supervisor 幻灯片，以及 hnshah 对“从计划走向判断”的总结，都收敛到控制平面、validator 或 critic 循环，以及持久化工件上。（来源）
- 平台 incumbents 正在比构建者更快地把信任缺口产品化。 joaomdmoura 把治理和可观测性点名为主要障碍；同一天，GitHub 和 Microsoft 就推出了原生 Agent 界面、MCP 支持的审查，以及受治理的上下文层。（来源）
- skills 正变得可安装、可移植，也越来越可度量。 Matt Pocock 的仓库、Skill RSI、Play Billing Skills 和 ACP 都把 skills 当成可安装、可跨 agent 迁移、可被评测的资产，而不是藏在 prompt 里的文本。（来源）
- Agent 商业在转移信任之前，已经能先转移资金。 AgenC、AgentLance 和 AllScale Checkout 展示了真实的支付和任务闭环，但回复始终回到验证、密钥所有权和可移植声誉这些问题上。（来源）
- 高信号的多 Agent 系统，开始出现在真实垂直领域，而不只是开发者工具里。 Co-Scientist 的公开发布表明，同样的 supervisor、辩论和排序模式，已经延伸到科学假设生成，并且有公开的合作者案例支撑。（来源）