Twitter AI Agent - 2026-05-11¶
1. 人们在讨论什么¶
1.1 Harness 工程正固化为一门运营学科 🡒¶
最大的一组证据表明,如今智能体工作的难点已经转向模型外围的系统:缓存、路由、评测、可观测性、搜索和上下文组装。与 5 月 10 日相比,相关表述变化不大,但 5 月 11 日的帖子更偏执行落地,少了些口号化表达。
@akshay_pachaar 发布了当天最强的一份检查清单,明确将 Harness 工程置于提示词工程之上,并将提示词缓存、语义缓存、KV-cache 管理、结构化输出回退机制、评测、成本归因、护栏、可观测性、路由以及微调取舍列为核心技能(帖子链接)。@0xNeoArch 的回复进一步强化了这一点,补充了提示词注入防御、蒸馏,以及判断何时根本不该使用 LLM。
@aiDotEngineer 又将这套栈进一步收束,称上下文工程“大约 80% 是 agentic search”,并把大家引向一个工作坊,讨论 shell 工具、语义搜索、通用查询执行和 skills 各自会在什么情况下失效(帖子链接)。@DataScienceDojo 则把同样的心智模型可视化为一条上下文流水线:在模型调用前后,将提示词、记忆、向量搜索、网页搜索和审阅者循环整合在一起(帖子链接)。

@hasantoxr 把这一说法落到具体工具组合上,建议研究 Harness、PostHog、GrowthBook、Chaos Mesh 和 Kubescape 等仓库(帖子链接)。相关仓库进一步强化了这种系统视角:Harness 将自己定位为开源开发平台,提供代码托管、流水线、Gitspaces 和 registries;PostHog 集成了分析、会话回放、功能开关、实验和 LLM 分析;GrowthBook 则结合了功能开关、实验、分析和 MCP server。
讨论洞察: 最有价值的回复并未反对 Harness 这一框架,而是在其基础上继续延展。反驳点在于,搜索质量、注入防御、路由和成本控制等传统工程问题依然占主导,只不过如今发生在概率型运行时里。
与前一天的比较: 5 月 10 日让 Harness 工程成为一个共同标签;到 5 月 11 日,这个标签已更接近一份实现检查清单和一张仓库/工具采购单。
1.2 智能体操作者希望界面更薄、范围更窄、轨迹可实时查看 🡕¶
第二个主题是,人们希望智能体工作在更小、更清晰、也更易读的环境里。大家要的不是更强的原始自主性,而是更清晰的契约、更窄的工作集,以及能直接证明智能体此刻在做什么的证据。
@ctatedev 认为,如果开发者从 index.html、浏览器原语、Web Components 以及对路由、渲染、状态变更和数据处理的严格约定出发,而不是依赖笨重框架,那么完全由智能体编写的前端或许会表现得更好(帖子链接)。回复里补充了两个具体方向:@bytecrafter_1 认为,更难的契约通常发生在智能体彼此之间,而不是 UI 原语之间;@noname_oni 则指向 W3C UI Specification Schema Community Group,认为它可让 UI 结构具备机器可读性。旁边的 Arrow 框架页面也体现了同样的倾向:强调无需构建步骤、只有三个核心函数,以及小到足以让智能体完整装入上下文的文档。
@pvncher 把范围问题说得很具体:如果打开的根目录里包含多个彼此无关的项目和 worktree,会伤害编码智能体的表现,因为模型会把目录树中过多内容视为相关(帖子链接)。他在回复中举例说,有一种情况里可访问的 worktree 达到 12 个,结果形成了 13 份文件副本,既浪费 token,也拖慢搜索性能。
@zaimiri 给出了最清晰的可观测性案例:他称赞 Hermes Agent 能实时显示哪些 skills 和工具正在触发;此前他曾多次遇到 OpenClaw 看起来闲置数分钟,最后却无声失败(帖子链接)。

@RhysSullivan 又把同一主题延伸到供应链控制,给出一条提示词,要求编码智能体为软件包安装配置至少三天的最小发布时间、豁免 workspace scopes,并在写入配置前核验包管理器的精确设置(帖子链接)。
讨论洞察: 回复反复把“对智能体友好”重述为“可调试”。用户想要的是协议、忽略边界和实时轨迹,让他们能够检查系统,而不是只能等待一团输出。
与前一天的比较: 5 月 10 日强调更薄的前端和更好的脚手架;5 月 11 日则补上了工作集纪律、实时执行轨迹和软件包策略控制。
1.3 Skills 正在成为具有独立生命周期的可移植资产 🡕¶
围绕 skills 的讨论也变得更具体了。构建者不再只谈 marketplace,而是展示了 skills 如何被安装、同步、从经验中提取、版本化,并在不同智能体之间复用。
@brian_lovin 分享了 notion-skills,这个工具把 Notion 数据库当作 skills 的应用商店,并将选中的 skills 同步到 Claude、Codex 等智能体的本地文件夹中(帖子链接)。公开的 代码库 显示,它支持安装、同步、发布、feed、反馈和审计流程,而且同一个 skill 可以通过符号链接接入多个智能体 CLI。Brian 在回复中表示,他的大部分 skills 都是由智能体编写的,而 Claude Code 和 Notion 已可通过 MCP 加 CLI 互通。
@tom_doerr 突出了 AutoSkill。该仓库将其描述为“由经验驱动的终身学习”:从真实交互、归档对话、文档和轨迹中提取可复用的 skills,再通过合并和版本更新持续演化(帖子链接)。README 还提到,新加入了一个本地 skill manager,用于分流、相似 skill 搜索,以及执行丢弃、改进、合并和创建等决策。

讨论洞察: 价值主张正从“找到更多 skills”转向“让正确的 skills 保持最新”。最有力的证据集中在同步、反馈、版本化,以及从真实使用中提取能力,而不是单纯的目录规模。
与前一天的比较: 5 月 10 日浮现的是 marketplace 和目录;到 5 月 11 日,skill 运营已更像软件包管理和生命周期管理。
1.4 多智能体记忆与机器可支付基础设施正以产品形态落地 🡕¶
最后一个强主题是产品化。多条帖子已经超出理论讨论,开始展示可持久化、可协作、可交易的智能体所需的具体界面、部署指标和支付基础设施。
@owenbjennings 表示,Mongoose 作为云端多智能体层已接近就绪:其中的 “mongeese” 可以共享来自网页、日历、Slack、电子邮件和文档的上下文,彼此辩论,并在 Goose OSS 之上积累复合记忆(帖子链接)。附带的 shell 截图让这一说法更具象:同一操作者界面中展示了 summon/build/skills/sentries/settings 命令。

@vercel_dev 指向 Superset。相关 Vercel 文章称,这是一个多智能体 IDE,可并行运行最多 12 个智能体,每周部署 1,000 到 1,400 次、每天约 600 次 preview deployments,平均构建时间约为 30 秒(帖子链接;博客)。产品页面表示,每个智能体都运行在各自隔离的 git worktree 中,并可与任何 CLI 智能体协作。
@circle 发布了 Circle Agent Stack,将其定位为面向智能体的金融基础设施,围绕 Agent Wallets、Agent Marketplace 和 Circle CLI 构建,使智能体能够在权限和护栏约束下执行可重复的金融操作(帖子链接)。Circle 的 文档 表示,这套栈让智能体可以持有并交易代币、发现并支付 x402 服务,并在内置的合规护栏内运行。与此同时,@graphprotocol 表示 Subgraph Gateway 现在已接受用于链上数据查询的 x402 付款;The Graph 的 指南 则表示,智能体可以通过 HTTP 以 USDC 付款,无需 API keys、账户或会话(帖子链接)。

讨论洞察: 围绕 Circle 的回复,关注点更多在编排层和 CLI,而非钱包本身。这说明市场真正看重的切入口,是可重复、受策略约束的操作,而不只是智能体持有余额。
与前一天的比较: 5 月 10 日更多讨论的是原则层面的治理与身份;到 5 月 11 日,则新增了已发布文档、定价界面,以及已上线产品的运营指标。
2. 什么让人沮丧¶
Harness 复杂性仍在吞噬模型带来的收益¶
最常见的挫败感在于,更好的模型并不能消除对更强系统工程的需求。@akshay_pachaar 将缓存、评测、路由、可观测性和回退机制列为必备技能,而 @aiDotEngineer 则把上下文工程压缩为搜索和工具选择。@dair_ai 又补充了一个有研究支撑的失败模式:相关 PwC 论文称,目标澄清在执行前 10% 之后会失去大部分价值,输入澄清则能更长时间地保持帮助,而过晚澄清甚至可能比从不提问更差。严重程度:高。当前的应对方式不是减少 Harness 工作,而是做更多。
范围过大的工作区和沉默的运行时仍在浪费时间¶
人们仍在遭遇与模型 IQ 无关的失败模式。@pvncher 描述了智能体会被含有大量无关项目和重复 worktree 的根目录搞糊涂,并在回复中表示,有一种配置会让模型看到每个文件的 13 份副本。@zaimiri 抱怨,有些智能体看起来会闲置六分钟,最后才暴露出自己其实什么也没做。严重程度:高。当前的应对方式是缩小范围、增加 ignore rules,并要求实时轨迹。
安全与策略控制仍落后于自主性¶
随着智能体承担越来越多操作,操作者希望默认设置更锋利。@RhysSullivan 将软件包发布时间控制描述为一项显而易见、却姗姗来迟的供应链攻击防护措施。@circle 强调金融操作中的权限与护栏,而 Circle 的 文档 则把合规和支出控制作为产品的一部分。严重程度:高。目前的应对仍是手动加固,以及事后叠加策略层。
3. 人们希望看到什么出现¶
轻量、面向智能体的 UI 与运行时约定¶
@ctatedev 希望有一套浏览器原生的前端约定,让智能体能够可靠地路由和修改;回复则要求把组件定义系统化,并指向 W3C UI Specification Schema Community Group。这个需求很务实,不是愿景式的:人们想要的是比当下默认框架栈更小、更适合机器读取的界面。机会:直接。
能随时间持续积累的 skill 生命周期工具¶
skills 这一簇里,最强的需求不只是发现。@brian_lovin 想要共享的安装/同步/发布/反馈流程,AutoSkill 则推动从真实交互中自动提取、合并并版本化演进。人们看起来想要的是一个“包管理器 + 更新日志 + 反馈闭环”,用来管理智能体能力。机会:直接。
既持续有用、又不损害操作者信任的持久记忆¶
@owenbjennings 推介了跨工作与沟通界面的持久共享上下文,而 OpenHuman 承诺提供基于本地 SQLite 的记忆树、兼容 Obsidian 的 vault、118+ 项集成,以及每 20 分钟自动抓取一次的循环。这个需求既务实也带有情感层面:人们希望智能体记住足够多的信息以保持有用,但前提是这种记忆必须可检查、可控制。机会:直接。
面向智能体、弱凭证化的支付与服务发现¶
Circle Agent Stack 和 The Graph 的 x402 Subgraph Gateway 从两个方向描述了同一个缺失层:智能体需要一种标准方式来发现服务,并按请求付费,而无需存储长期凭证。The Graph 的指南明确指出,x402 访问不需要 API keys、账户或会话,因此非常适合自主型或短生命周期进程。机会:竞争性。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Harness 工程 / 上下文工程 | 方法 | (+) | 为缓存、评测、路由、可观测性、护栏和成本归因提供共同框架 | 范围仍足够宽泛,不同人指代的层次并不一致 |
| Agentic search | 检索方法 | (+) | 将搜索和工具选择视为上下文组装的核心,而不是事后补丁 | 运行时若选错抽象层,工具选择可能严重失效 |
| 浏览器原语 + Web Components + Arrow | 前端方法 | (+/-) | 更小的表面积、无需构建的选项和更简单的约定,适合智能体编写 UI | 把更多契约设计工作转嫁给构建者;回复也指出协议边界仍然更重要 |
| 限定根目录 / worktree 过滤 | 工作区方法 | (+) | 可减少编码智能体中的 token 浪费、重复文件混淆和搜索变慢 | 当工作跨越紧密耦合的仓库时更难实施 |
| 实时工具与 skill 轨迹 | 可观测性 | (+) | 让智能体在运行过程中即可调试,而不必等超时后再排查 | 证据仍局限于特定生态,且总体偏早期 |
| Notion Skills | Skill 分发 | (+) | 提供共享存储、选择性安装、双向同步、发布、反馈和审计,并支持多个智能体 | 仍属早期工具,且以 Notion 作为事实来源 |
| AutoSkill | Skill 演进 | (+) | 从交互、文档和轨迹中提取可复用 skills,再进行合并和版本化 | 仍偏研究导向,且依赖对真正可复用内容进行良好分流 |
| Circle Agent Stack | 智能体金融基础设施 | (+) | 为可重复的资金流转增加钱包、市场发现、CLI 操作和护栏 | 生态专属性较强,相比通用开发者工具仍偏早期 |
| The Graph x402 gateway | 智能体 API 访问 | (+) | 通过 HTTP 按查询使用 USDC 支付,无需 API keys、账户或会话 | 更适合兼容 x402 的生态,而非通用服务访问 |
| 澄清时机框架 | 智能体评测方法 | (+) | 为长时程智能体在何时提出澄清问题仍有帮助提供了具体指导 | 这是研究结果,不是开箱即用的运行时功能 |
总结: 正向情绪主要集中在那些让智能体更容易限定范围、检查和复用的工具上。最清晰的迁移路径,是从只谈提示词转向上下文组装、skill 封装、运行时可见性和策略控制。竞争压力正在分化:一端是开放式构建者工具,另一端则是托管式支付/治理层。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Notion Skills | @brian_lovin | 将 Notion 作为共享的 skill store,并把选定的 skills 同步到本地智能体文件夹 | Skill 文件分散在不同机器、文件夹和团队成员之间 | Notion、Node.js、通过符号链接安装 SKILL.md |
Alpha | 代码库, 帖子 |
| AutoSkill | ECNU-ICALK | 从交互、文档和轨迹中提取可复用 skills,并持续演化 | 优秀的智能体行为会在一次性会话后消失 | SKILL.md、离线提取、本地 skill manager、版本化 skill 更新 |
Alpha | 代码库, 帖子 |
| Mongoose | @owenbjennings | 提供带共享上下文和复合记忆的云端多智能体编排 | 助手通常会丢失跨界面的上下文和团队连续性 | Goose OSS、共享上下文编排、持久记忆 | Alpha | 帖子 |
| Superset | Superset | 提供带隔离 worktrees 和实时预览基础设施的多智能体 IDE | 当分支和环境排队时,并行编码智能体会被迫串行化 | AI SDK、AI Gateway、Blob、Fluid Compute、git worktrees | 已发布 | 网站, 博客, 帖子 |
| Circle Agent Stack | Circle | 为智能体提供钱包、marketplace 发现和由 CLI 驱动的金融操作 | 智能体需要机器可支付的服务,以及受护栏约束的资金流转 | Agent Wallets、Circle CLI、x402 服务、USDC | Beta | 文档, 帖子 |
| OpenHuman | tinyhumansai | 提供本地优先的个人智能体,包含记忆树、Obsidian vault、集成和模型路由 | 大多数智能体一开始都是冷启动,并把上下文碎片化地散落在各个应用中 | SQLite、Markdown/Obsidian、OAuth 集成、TokenJuice、可选 Ollama | Beta | 代码库, 帖子 |
| Voice ordering agent | @EstebanSuarez | 通过语音工作流构建购物车、发送订单、收集电子邮件并发送收据 | 展示语音智能体如何完成结构化操作,而不只是聊天 | v0、Grok Voice Think Fast 1.0、Resend、六个自定义函数工具 | Alpha | 帖子 |
这些项目大致聚成三种反复出现的模式。第一类是在构建能持续复利的智能体基础设施:skills、记忆、编排和 worktree 隔离。第二类试图通过钱包、按请求计费和服务发现,让智能体具备金融能力。第三类则利用这些基础能力展示更窄的应用工作流,例如语音下单,其重点是可靠完成任务,而不是对话质量。
6. 新动态与值得关注的内容¶
递归委派正成为训练目标¶
@gneubig 突出了新的 Recursive Agent Optimization 论文。该论文训练智能体生成并协调递归子智能体,而不是把委派仅仅当作手写的推理时技巧(帖子链接;论文)。摘要称,以这种方式训练的递归智能体能够扩展到超出单个上下文窗口的任务,并且相较于单智能体系统,还可减少 wall-clock time。
澄清时机如今有了量化曲线¶
@dair_ai 提出了一篇关于长时程智能体澄清时机的 PwC 论文(帖子链接;论文)。论文报告了 84 个任务变体和 6,000+ 次运行,并称目标澄清在执行 10% 之后便失去大部分价值;输入澄清的有效期长得多;一旦超过中点,任何澄清都可能不如完全不问。
软件包发布时间策略正在进入编码智能体操作手册¶
@RhysSullivan 那条关于最小发布时间的帖子之所以突出,是因为它把一个普遍的供应链问题,转化为编码智能体操作者可直接执行的具体习惯。真正值得注意的不是玩笑式回复,而是人们越来越期待智能体代为配置、验证并执行这些加固规则。
7. 机会在哪里¶
[+++] 智能体运行时控制平面 —— 最强证据横跨限定根目录、实时工具轨迹、供应链策略和金融护栏。构建者希望智能体不仅能行动,也能被监督和约束。
[+++] Skill 生命周期基础设施 —— Notion Skills 和 AutoSkill 都指向一个缺失层:用于安装、同步、审查、版本化,以及自动提取可复用能力。
[++] 具备操作者可见性的持久记忆系统 —— Mongoose 和 OpenHuman 展示了对这类智能体的需求:启动快、能跨工具记忆,但又以用户可检查、可引导的形式存在。
[++] 弱凭证化的服务发现与支付 —— Circle Agent Stack 和 The Graph 的 x402 流程都指向一个不断增长的市场:无需长期密钥的按次付费型智能体基础设施。
[+] 面向智能体的应用约定 —— 轻量前端栈、UI 规范探索和无需构建的框架,表明一个专为机器编写与审查而设计应用表面的机会正在浮现。
8. 要点¶
- 围绕智能体的讨论仍然以基础设施为先。 当天信号最强的帖子都在谈 Harness、搜索、轨迹、skills 和控制界面,而不是原始模型对比。(来源)
- 可读性正成为产品质量的一部分。 关于轻量前端、限定根目录、实时轨迹和软件包发布时间控制的帖子,指向的是同一标准:用户希望看见并约束智能体在做什么。(来源)
- Skills 被越来越少地当作提示词,越来越多地当作软件制品。 安装、同步、发布、反馈、提取和版本化,都以一等行为的形式出现在最强的 skill 相关内容中。(来源)
- 产品化的多智能体与支付基础设施已不再只是设想。 Superset、Mongoose、Circle Agent Stack 和 The Graph 都给出了具体界面或运营指标,而不只是类别层面的表述。(来源)