Twitter AI Agent - 2026-05-28¶
1. 人们在讨论什么¶
1.1 Harness engineering 逐渐固化为一门有明确名称的系统学科 🡕¶
5 月 28 日最明显的变化是，harness engineering 不再只是松散的行话，而开始成为人们理解智能体系统实际构建方式的一张共同地图。至少有四条入选内容支撑了这一主题。
@_vmlops 分享（53 个赞、2 条回复、3,907 次浏览、73 次收藏）介绍了 awesome-harness-engineering 集合。公开的 仓库 将 harness engineering 定义为围绕智能体的脚手架：上下文交付、工具接口、规划工件、验证闭环、记忆系统和沙箱，并用具体原语来组织这一领域，而不是围绕模型炒作展开。
@koylanai 表示（33 个赞、4 条回复、1,243 次浏览、35 次收藏）提到，一篇新的综述论文审查了 170 多个开源项目，以及 OpenAI、Anthropic 和 LangChain 的生产经验。附图是其中最有价值的部分：它明确区分了 prompt engineering、context engineering 和 harness engineering，并增加了一个七层分类体系，涵盖执行环境、工具接口、上下文管理、生命周期/编排、可观测性、验证和治理。
@MrAhmadAwais 认为（43 个赞、2 条回复、4,475 次浏览、8 次收藏）指出，Claude Code 在开放模型上仍存在严重的工具调用问题，而大部分修复都发生在 harness 层，而非模型本身。这与公开的 Outcome School 讲解 形成了清晰呼应：后者将 harness 描述为围绕模型、负责管理工具、记忆、错误、评估和护栏的控制层。
讨论洞察： 最强烈的分歧来自 @ricklamers 这类人。反驳（4 个赞、1,154 次浏览、6 次收藏）认为，简单系统有时比高度工程化的 harness 泛化得更好。但即便是这种批评，也接受了当天讨论的基本前提：争论的是 harness 需要做到什么程度，而不是 harness 是否重要。
与前一天相比： 5 月 27 日对 harness 的讨论还主要围绕沙箱、记忆新鲜度和遥测；到了 5 月 28 日，它已经通过精选资料、综述分类法，以及运营者修复具体工具调用故障的案例，被推进成一门更完整的学科。
1.2 持久化智能体需要共享状态、索引和跨模块连续性 🡕¶
第二个强势主题是：一旦智能体跨越模块、代码仓库或应用边界，真正困难的就不再是模型能力本身，而是共享状态。至少有三条入选内容支撑了这一主题。
@chamath 宣布（113 个赞、20 条回复、64,346 次浏览、44 次收藏）提到，8090 Software Factory 推出了一个可跨模块持续存在的统一智能体，下一步计划是多仓库索引。公开的 8090 网站 将 Software Factory 描述为一个 AI-native SDLC 控制平面，围绕文档、监督和完整审计轨迹构建。这使“统一智能体”的卖点不只是聊天机器人的便利性，而是让上下文能够在企业工作流中持续存活。
@BankQuote 描述（200 个赞、22 条回复、5,312 次浏览、27 次收藏）将 KasGraph 描述为 Kaspa 面向钱包、浏览器、DeFi 界面和 AI 智能体的共享索引层。这条帖子细节异常丰富：用 GraphQL SDL 定义 schema，用 AssemblyScript 将 TypeScript 事件处理器编译为 WASM，将索引数据物化到 Postgres，设置 proof-of-indexing 检查点，并通过 GraphQL、MCP、gRPC streaming 和 WebSocket subscriptions 提供访问。线程下的回复也把需求说得很明确，@Kas_Ranks 表示他们一直在等一个统一索引器。
@GuappGet 定位为（25 个赞、5 条回复、1,292 次浏览）介绍了 Goblintown：一个面向多智能体编排的 local-first 桌面应用，设有 worker、critic、memory、judge 和 delivery 等独立角色。这只是同一模式的另一种封装：一旦工作变成长周期任务，团队想要的是角色分工、可恢复性和共享上下文界面，而不是单一、无差别的聊天循环。
讨论洞察： 这里的回复主要围绕交接成本、协同和复用。人们具体想要的不是更聪明的孤立模型，而是一个持久化界面：每当工作在模块或智能体之间流转时，不会丢失状态、索引或路由逻辑。
与前一天相比： 5 月 27 日强调的是智能体组织结构和后台桌面控制；5 月 28 日则通过统一智能体、共享索引器和 local-first 编排外壳，把“连续性层”更明确地摆到了台前。
1.3 Skills 被视为可复用资产，智能体可以编写、审计并做基准测试 🡕¶
Skills 也进一步摆脱了静态提示词文件，开始转向可复用的运行资产：智能体可以生成，人类可以审阅。至少有三条入选内容支撑了这一主题。
@MervinPraison 报道（5 个赞、2 条回复、349 次浏览、7 次收藏）提到，一个 Hermes 智能体读取 CLI help 后，正确生成了自己的 SKILL.md、脚本和触发器。这一点之所以重要，是因为它把 skills 视为机器生成的工作文档，而不是人工编写的提示词迷信产物。
@bradmillscan 分享（8 个赞、3 条回复、1,036 次浏览、6 次收藏）介绍了一组 Hermes skill proficiencies 入门集合，例如 Tidy、Methodical、Helpful 和 Thorough。链接中的 仓库 将这些特质转化为可检查的工件，用于工作区卫生、SOP 生成和发布，比含糊的“最佳实践”建议更具操作性。
@koylanai 补充说（33 个赞、4 条回复、1,243 次浏览、35 次收藏）提到，新综述明确引用了 Agent Skills for Context Engineering，进一步说明 skills 正在被当作生产 harness 的一部分来讨论，而不是模型之外的事后补丁。
讨论洞察： 大家的共同偏好是可见、可移植的 skill 文件：可以审阅、编辑，并能跨运行时迁移。这与把 prompts 当作隐藏实现细节完全不同。
与前一天相比： 5 月 27 日聚焦于编辑器原生 skills 和 skill 优化研究；5 月 28 日则把这一思路推进到了自生成 skills、proficiencies，以及研究支持下的“skills 作为核心 harness 原语”。
1.4 智能体经济市场扩散得比硬证据更快 🡒¶
最具投机色彩的一组讨论，集中在市场、变现和“智能体经济”上。这个主题确实存在，但公开证据明显弱于 harness 和基础设施相关帖子。至少有四条入选内容支撑了它。
@swarms_corp 主打（39 个赞、6 条回复、1,274 次浏览）介绍了一个自治市场：微型智能体可以发现、评估、部署和交易智能。@agentranking 描述（21 个赞、4 条回复、348 次浏览）则介绍了一个面向付费 API 调用、订阅、MCP 服务器和机器可支付工具、按声誉排序的市场。
@nottellingyou73 声称（22 个赞、6 条回复、6,692 次浏览、6 次收藏）提到一个与 Robinhood 关联的交易智能体市场已开放早期访问；与此同时，@trythreews 推出（7 个赞、1 条回复、40 次浏览）提到 AWS Marketplace 上的 three.ws，其宣称开发者只需一个标签，就能在链上和任意网页嵌入 3D AI 智能体。
讨论洞察： 与 harness 和数据层讨论相比，这些市场类帖子更多使用未来式表述，运营细节则更少。这个概念显然已获得注意力，但关于其持久价值，最有力的证据仍然来自底下那些不那么光鲜的基础设施。
与前一天相比： 5 月 27 日已经出现了专业化运营者和工作区；5 月 28 日则把这股势能包装进“智能体经济”和变现叙事中，尽管公开证据仍然偏早期。
2. 什么让人感到沮丧¶
真实智能体栈中的工具调用可靠性仍然脆弱¶
严重程度：高。最现实的挫败感在于，开放模型智能体往往还没轮到用户评估模型本身，就先在 harness 层失败了。@MrAhmadAwais 表示（43 个赞、2 条回复、4,475 次浏览、8 次收藏）指出 Claude Code 在开放模型上存在严重的工具调用问题，@_vmlops 将其定义为（53 个赞、2 条回复、3,907 次浏览、73 次收藏）则把这些失败归因为围绕上下文、工具、记忆和验证的脚手架问题。即便是持怀疑态度的 @ricklamers，也是在说过度构建的 harness 可能损害泛化能力。当前的应对方式不是盲目信任，而是持续调整 harness、尽量采用更简单的循环，并进行明确评估。这个方向值得投入，因为故障发生在用户还无法从智能体获得稳定产出之前。
治理与权限边界仍然定义不足¶
严重程度：高。最强烈的安全相关抱怨，并不是对智能体的抽象恐惧，而是不确定多智能体系统一旦接入真实工具和真实基础设施，会发生什么。@VivekIntel 展示了（30 个赞、2 条回复、1,427 次浏览、31 次收藏）介绍了自主渗透测试框架 PentestAgent，而最有价值的一条回复立刻追问：工具执行和权限边界究竟如何约束。@anton_chuvakin 强调（8 个赞、929 次浏览、9 次收藏）提到了论文 Agent Security is a Systems Problem，而 @WisemanCap 指出（26 个赞、2 条回复、4,013 次浏览）则提到 Snowflake 正在收购 Natoma 以补强智能体治理。当前的缓解模式，是在智能体外层加入策略、审计和特权访问控制，而不是让自主性裸奔。
团队仍在重复搭建相同的索引、记忆和协同界面¶
严重程度：中高。KasGraph 和 Software Factory 的帖子暴露出一种反复出现的基础设施税：几乎每个严肃的智能体工作流都需要自己的索引器、连续性层或路由界面。@BankQuote 明确说明（200 个赞、22 条回复、5,312 次浏览、27 次收藏）列出了每个 Kaspa 应用最终都要回答的那些重复问题，@chamath 出售（113 个赞、20 条回复、64,346 次浏览、44 次收藏）则提到统一智能体的一个目标，就是减少模块交接。@GuappGet 补充说（25 个赞、5 条回复、1,292 次浏览）介绍了一个带有专用记忆和审阅角色的 local-first 多智能体外壳。这种挫败感并不华丽，但它是结构性的，而且反复出现。
市场叙事跑在了信任和验证前面¶
严重程度：中。智能体市场相关帖子吸引了大量注意，但证据密度落后于 harness 和基础设施这一簇。@swarms_corp 谈到（39 个赞、6 条回复、1,274 次浏览）谈的是智能体经济，@agentranking 推广（21 个赞、4 条回复、348 次浏览）谈的是按声誉排序的变现能力，@nottellingyou73 提出（22 个赞、6 条回复、6,692 次浏览）谈的是交易智能体的早期访问。缺少的是同样级别的公开细节：故障处理、治理机制，以及能否持续为运营者创造价值。对任何试图搭建商业层的人来说，这都留下了可信度缺口。
3. 人们希望看到什么¶
可移植、可修复、可度量的 harness¶
信息流中最强烈的愿望，并不是一个新的前沿模型，而是能明确显示某次改动是否真的带来改善的 harness。harness-engineering repo、新综述，以及 Claude Code 的工具调用问题，都指向同一个缺口。构建者想要的是：工具使用、上下文组装、验证和安全方面都能获得可度量的提升，而不是靠猜。机会：直接。
面向持久化智能体的共享数据与连续性层¶
KasGraph、Software Factory 和 Goblintown 都暗示着同一个未满足需求：为必须跨模块、仓库或产品持续运行的智能体提供可复用的控制平面和数据平面。如今，很多团队仍在从零开始构建自己的索引器、记忆层和协同外壳。机会：直接且竞争激烈。
面向 MCP、工具和特权操作的默认安全治理¶
安全讨论的结论很一致：一旦智能体接入在线工具，团队想要的是强边界，而不是只靠提示词来提醒谨慎。PentestAgent 引发的反应、Natoma 收购信号，以及那篇系统安全论文，都指向一种需求：身份、策略、审计和最小权限控制，而且这些能力必须能自然融入智能体工作流。机会：直接。
能由智能体生成、审阅并改进的 skill 系统¶
Hermes 和 skill-proficiency 相关帖子表明，团队想要的不只是一个静态提示词文件夹。他们希望 skills 能从真实工作中生成，像代码一样被检查、做基准测试，并在不同运行时之间迁移。这更像一个实际需求，而不是空想。机会：直接且竞争激烈。
面向智能体市场的信任与声誉层¶
市场类帖子正在增多，但信任层明显建设不足。如果智能体能力要被购买、出售、订阅，或被机器对机器调用，构建者就需要能经受真实运营者审查的声誉、沙箱、策略和计费系统。机会：新兴。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| awesome-harness-engineering | 参考资料集合 | (+) | 为构建者提供一张涵盖上下文、工具、记忆、验证和沙箱的统一地图 | 它是资料集，不是可执行运行时 |
| Agent Harness Engineering: A Survey | 研究框架 | (+) | 形式化提出七层分类体系，并梳理 170 多个开源项目 | 偏概念，而非开箱即用 |
| 8090 Software Factory unified agent | 智能体平台 | (+/-) | 持久化跨模块智能体流，带审计轨迹、文档和监督 | 公开技术细节仍少于产品层面的表述 |
| KasGraph | 数据/索引层 | (+) | 提供 GraphQL、WASM、Postgres、MCP、gRPC 和 WebSocket 等可复用状态访问界面 | 仍处早期，且面向特定生态 |
| PentestAgent | 安全运营工具 | (+/-) | 支持 assist/agent/crew 模式，提供 Docker 或 Kali 隔离、报告生成和 MCP 支持 | 领域敏感，权限和范围控制极其重要 |
| Hermes proficiencies | Skill 包 | (+/-) | 将工作区纪律和 SOP 转化为可移植的 skill 资产 | 目前证据仍停留在线程层面，且较早期 |
| three.ws | 智能体界面 / 变现 | (+/-) | 支持可嵌入的 3D 智能体、MCP 和 A2A，并提供可移植身份与计费接口 | 目前更多证明了界面与变现可能性，尚未充分证明运营价值 |
总体来看，人们更青睐那些让控制界面更加明确的工具。资料集合、分类体系和基础设施层获得了最干净的正向反应，因为它们让智能体行为更容易被理解。终端用户市场，以及进攻性安全运营工具，则引发了更复杂的情绪：上行空间显而易见，但治理和信任要求也高得多。当天的迁移路径，是从以 prompt 为中心的思维，转向以脚手架为中心的思维：上下文、策略、编排、修复闭环和可复用 skills。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| KasGraph | @BankQuote | 面向 Kaspa 应用和智能体的 subgraph 风格索引层 | 否则每个应用都得自己重建代币、covenant、NFT、转账和证明索引 | GraphQL SDL、TypeScript、AssemblyScript/WASM、Postgres、MCP、gRPC、WebSocket | Alpha | 帖子 |
| 8090 Software Factory unified agent | 8090 | 在 AI-native SDLC 平台内跨模块运行的持久化智能体 | 企业软件交付中的跨模块交接成本与上下文丢失 | AI-native SDLC 控制平面、文档层、审计轨迹、多仓库索引路线图 | Beta | 网站, 帖子 |
| PentestAgent | GH05TCREW | 支持 assist、agent 和 crew 模式的自主渗透测试框架 | 可重复的侦察、利用与报告流程仍然高度依赖人工 | Python、LiteLLM 支持的模型、终端和浏览器工具、Docker 或 Kali、MCP | Shipped | 仓库 |
| Goblintown | @GuappGet | 面向单智能体和多智能体编排的 local-first 桌面应用 | 复杂工作需要角色分工、可恢复性、预算控制和审阅闭环 | Local-first 桌面应用、多智能体角色、签名输出、预算控制 | Alpha | 帖子 |
| three.ws | three.ws | 让构建者通过一个标签，将完整具身的 3D AI 智能体嵌入链上和网页 | 智能体仍缺少可移植的前端身份与分发界面 | Web components、GLB/gltf 渲染、Solana、Metaplex Core、MCP、A2A | Beta | 网站, 帖子 |
KasGraph 和 8090 Software Factory 虽然从相反方向切入，却指向了同一种构建模式。一个起点是区块链基础设施，另一个起点是企业 SDLC，但两者的大部分精力都花在连续性上：共享状态、可复用索引，以及更少的交接。
PentestAgent 是当天最清晰的运营型构建项目。它的公开 repo 已经记录了多种执行模式、Docker 和 Kali 隔离、MCP 支持以及内置报告，因此比许多叠加在“智能体经济”叙事之上的市场化方案更具体。
Goblintown 和 three.ws 则展示了构建者在界面侧的实验方向。Goblintown 把编排变成一个基于角色的桌面外壳；three.ws 则把智能体变成可嵌入的前端界面，并附带可移植身份和变现接口。两者都值得关注，但就目前证据来看，仍早于底层控制平面的工作。
6. 新动态与值得关注的事¶
Harness engineering 有了自己的公开资料谱系¶
awesome-harness-engineering repo、新综述以及配套解读的组合，让 harness engineering 看起来更像一个已经稳定下来的术语，而不再是短暂流行的梗。这很重要，因为它给构建者提供了讨论上下文、工具、验证和治理的共同语言。（仓库）
统一智能体开始在公开产品表述中取代按模块划分的智能体¶
8090 的统一智能体发布，在叙事上是一次重要变化。它承诺的不是“更多智能体”，而是一个可以跨越模块边界持续存在的智能体，并在整个工作流中保留对话历史、skills 和提醒。（来源）
自写 skills 从理论走向日常演示¶
Hermes 生成自己的 SKILL.md、脚本和触发器，这是一条篇幅不大但意味深长的帖子：skills 现在正被当作任务完成后可由智能体亲自编写的工作产出，而不只是人工预先配置的静态设定。（来源）
7. 机会在哪里¶
[+++] 持久化工作所需的智能体控制平面与数据平面 —— Software Factory、KasGraph 和 Goblintown 都指向同一个结构性需求：一旦智能体离开单任务循环，就需要持久化上下文、共享索引、编排能力，以及更少的交接。
[+++] 面向智能体 harness 的治理与修复工具 —— 工具调用故障、Natoma 的收购信号、PentestAgent 引发的权限问题，以及那篇系统安全论文，都表明市场需要审计、策略、范围控制和可度量的 harness 修复能力。
[++] Skill 生命周期平台 —— 综述中的引用、Hermes 自生成 skills 和 Hermes proficiencies 都表明，团队需要一种能跨运行时创建、做基准测试、审阅并迁移 skills 的方式。
[+] 面向智能体市场的信任与声誉基础设施 —— Swarms、AgentRanking、交易智能体方案和 three.ws 说明商业层正在形成，但关于持久信任和运营级控制的证据仍然偏早期。
8. 要点¶
- Harness engineering 是 5 月 28 日 AI 智能体讨论中最主导的解释框架。 最清晰的证据来自
awesome-harness-engineeringrepo 和那篇新综述论文；两者都把这项工作定义为上下文、工具、验证、编排和治理，而不仅仅是模型调优。（仓库） - 持久化智能体越来越需要共享状态和索引，而不是更多模型新奇性。 8090 的统一智能体和 KasGraph 的索引器，都把连续性而非模型原始智力，当作真正的瓶颈。（来源）
- Skills 正在变成可检查的运行资产。 Hermes 生成自己的 skill，以及 Hermes proficiencies repo，都指向一种趋势：skills 可以像代码一样被审阅、复用和改进。（来源）
- 市场叙事扩张的速度快于公开验证的运营价值。 AgentRanking、Swarms 和交易智能体相关帖子让商业层变得可见，但最具体的技术证据仍然来自底层基础设施。（来源）