Twitter AI Agent - 2026-06-16¶
1. 大家在讨论什么¶
1.1 Agent 框架正从理论走向可持久运行的生产级 harness（🡕）¶
6 月 16 日最明显的变化，是讨论从抽象的 harness 概念转向具体的框架发布与工作流界面。至少有四条强信号支撑这一主题：Flue 1.0 Beta、Linear 的“软件工厂”演示、Bottega 的编排仓库，以及围绕 HarnessX 持续展开的讨论——生产级 harness 到底必须控制哪些环节。
@FredKSchott 发布（492 次点赞，39 条回复，80,484 次浏览，444 次收藏）Flue 1.0 Beta 被定位为一个 TypeScript 框架，围绕工作流、自主 agents 和 channels 组织。公开的 Flue 仓库 补充了推文里只略微提到的细节：持久执行、安全沙箱、subagents、类型化工具和可复用 skills，都属于同一个 harness 的组成部分，这使它不只是某个模型 API 的轻量封装。
@karrisaarinen 展示了（73 次点赞，11 条回复，4,646 次浏览，39 次收藏）Linear 将一个 Intercom issue 路由进分诊、调查、编码会话，以及一个可直接进入评审的修复流程，整个过程大约十分钟。截图之所以重要，是因为它把“软件工厂”这种说法变成了可见的产品界面：issue、调查和代码工作流被呈现为一个连续的、由 agent 辅助的闭环，而不是若干彼此割裂的工具。
@ChrisShort 重点介绍了（1 次点赞，78 次浏览）Bottega，一个“以规范加可运行参考实现形式发布”的编排工具。仓库将这一循环解释为：人工定义任务 -> 规划 agent -> 实施 agent -> 对抗式审查循环 -> PR 处理；而 Claude Code、Codex 和 OpenCode 都可以在同一个任务中使用。
讨论洞察： 最值得注意的回复不是称赞，而是怀疑。有人在回复 Flue 时调侃说，“零 LLM 锁定”很容易承诺，却很难定义，这说明市场确实想要可持久的框架，但仍在质疑这些抽象到底有多强的可移植性。
与前一天对比： 6 月 15 日强调的是 harness 工程作为一门纪律；到了 6 月 16 日，这场讨论已经推进到可发布的产品和可见的团队工作流。
1.2 Skills 成为专业化与优化的主要单位（🡕）¶
第二个重要主题是，构建者越来越把 skills 当作一等工件来看待：需要精心编写、持续优化、可从 marketplace 安装，并针对狭窄领域定制。这一主题至少有五条强信号支撑，横跨建议、仓库和优化系统。
@mattpocockuk 认为（277 次点赞，21 条回复，11,088 次浏览，221 次收藏）指出，高效的 skills 往往依赖“Leitwörter”——会反复出现在 agent 自身推理轨迹中的引导词，并据此塑造行为。这让 skill 的讨论异常具体：它不再只是说“写更好的 prompts”，而是点出了构建者可以直接在 skill 文件中测试的一种具体写法。
@sharbel 提到了（32 次点赞，7 条回复，830 次浏览，29 次收藏）agent-skills，一个拥有 60,800+ stars 的仓库，把 coding-agent 的工作映射为斜杠命令，例如 /spec、/plan、/build、/test、/review 和 /ship。该仓库还通过记录 Claude Code、Gemini CLI、Copilot、Cursor、Windsurf 等多种环境下的安装路径，强化了这一判断：它证明的是流程可移植性，而不只是某个单一工具的小技巧。
@sivalabs 分享了（29 次点赞，1,057 次浏览，42 次收藏）spring-boot-skills，其 README 写道，通用 coding agents 会臆造过时的 Spring Boot 模式，并忽略项目特定约定。@tom_doerr 链接到（17 次点赞，2,125 次浏览，23 次收藏）altimate-code，一个数据工程 harness，包含确定性 SQL 分析、lineage、dbt tooling 和本地可观测性。这两个仓库共同展示了同一种模式：团队正在把领域知识打包成 skills，因为通用 agents 仍会遗漏太多上下文。
优化层也在推进。SkillOpt 仓库 在围绕 agent skills 的更广泛讨论中被提及，它描述了一个用于编辑 best_skill.md 工件的留出验证门，并预告了一个面向本地 coding agents 的夜间“SkillOpt-Sleep”循环。与此同时，Google 的 gemini-skills 仓库则把 skills 定义为轻量级上下文包，可在多个 CLI 中浏览和安装。
讨论洞察： 关于 skills 的讨论，已经不再只是“一次性写好指导”。证据指向的是一个完整生命周期：精心编写、对照 evals 调优、打包供安装，以及在通用行为失效时按领域收窄。
与前一天对比： 6 月 15 日已经高度聚焦于 skill 的可移植性。到了 6 月 16 日，仓库层面的证据更多了，也有更多团队把 skill 文件本身当作可部署工件。
1.3 能处理资金的 agents 成为明确的构建目标（🡕）¶
信息流中还显示，围绕 agent 的支付与商业基础设施显著增多。最强信号不再是模糊的“agent economy”说法，而是对钱包、服务发现、支出控制、黑客松，甚至可变现 3D agents 的具体描述。
@NousResearch 开源了（660 次点赞，51 条回复，68,375 次浏览，352 次收藏）一场与 NVIDIA 和 Stripe 联合举办的黑客松，面向构建能够赚钱、花钱并运行业务流程的 agents。帖子点名了具体组成部分——用于安全执行的 NemoClaw、作为运行时的 Nemotron 3 Ultra，以及可用于购买服务和开通 SaaS 的新 Stripe skills——这使该挑战成为平台方希望吸引构建者关注方向的强信号。
@circle 演示了（158 次点赞，16 条回复，6,597 次浏览）Circle Agent Stack 被描述为这样一套流程：agent 创建一个由 USDC 注资的钱包、发现服务、为 API 访问付费，并通过 Circle CLI 执行动作。Circle 关于 Agent Stack 的发布帖也公开确认了同样的架构：Agent Wallets、Agent Marketplace、CLI、Nanopayments 和 Circle Skills，外加权限控制与 guardrails。
@HermesAgentTips 重新定义了（33 次点赞，2 条回复，2,341 次浏览，15 次收藏）用非常直白的话描述了 Stripe 集成：agents 已经从回答问题，走向了花钱。被引用的 Nous 帖子补充了一个关键限定：每个动作都带有可配置的安全限制，这表明即便是最激进的支付演示，现在也必须把控制界面和自主性一同展示出来。
@nichxbt 分享了（65 次点赞，13 条回复，980 次浏览）three.ws，一个面向 3D AI agents 的开放栈，包含 WebXR 放置、语音与面部捕捉、USDC 按次聊天付费、区块链身份以及 MCP/A2A 连接能力。这个项目之所以重要，是因为它把具身化和变现整合进了同一个产品，而不是分散成彼此独立的实验。
讨论洞察： 回复并没有质疑 agents 能不能花钱；大家质疑的是，信任边界该划在哪里。当天最有力的问题非常实际：你到底会信任 agent 自主购买什么？
与前一天对比： 6 月 15 日已经出现了 marketplaces 和结算通道，但 6 月 16 日更强调可操作的支付栈，以及围绕它们形成的构建者激励。
1.4 信任与评估开始收紧到明确的证明界面（🡕）¶
第四个主题是，信任越来越少以笼统的治理语言来表达，越来越多通过明确阈值、eval gates 和 proof surfaces 来体现。最强证据来自 SDLC 白皮书讨论、HarnessX 的留出评估逻辑，以及一个体量较小但很有辨识度的 AgentProof 演示。
@DataChaz 总结了（51 次点赞，14 条回复，3,577 次浏览，60 次收藏）用 Google 那篇 50 页的 Vibe Coding 时代的新 SDLC 白皮书指出，大多数 agent 失败其实是 harness 失败，而不是模型失败。推文把这一观点落到了具体层面：静态上下文、动态 skills 与检索文档、严格 evals，以及部署 guardrails，而不是抽象的“最佳实践”。
@dair_ai 介绍了（206 次点赞，12 条回复，10,082 次浏览，224 次收藏）将 HarnessX 描述为一种可组合 harness，能从 traces 中演化；而 @akshay_pachaar（182 次点赞，11 条回复，19,390 次浏览，239 次收藏）解释了 则解释说，只有当编辑结果经过类型检查，并在留出验证门之后才被接受，这件事才成立。这里的独特之处并不只是“自我改进”，而是受明确验证约束的自我改进。
@genrih99999 展示了（18 次点赞，2 条回复，298 次浏览）AgentProof 这一系统会把私有 agent 数据转化为公开的阈值声明，例如 completedTasks >= 10 或 safetyScore >= 85。公开的 AgentProof 网站 将该产品描述为“基于私有记录的公开证明”，而一张经过评审的截图让其机制显得格外直观。
讨论洞察： 数据并没有显示出人们对盲目自主性的强烈偏好。它显示出的，是对那种能够证明某件具体事情的自主性的偏好：某个阈值已满足、某个 gate 已通过，或者某个有边界的工作流被正确执行。
与前一天对比： 6 月 15 日强调的是签名 traces 和治理界面。到了 6 月 16 日，这一方向进一步延伸为明确阈值、信任注册表和验证规则，可以在 agent 获得资金或工作权限前先行检查。
2. 什么让人沮丧¶
Harness 重写和薄弱评估仍在阻碍生产落地¶
严重程度：高。@dair_ai 表示（206 次点赞，12 条回复，10,082 次浏览，224 次收藏）指出，大多数 agent harness 仍是手工打造的，而且模型或任务一变，基本就得重写。@akshay_pachaar（182 次点赞，11 条回复，19,390 次浏览，239 次收藏）则把这种痛点进一步推深：一旦 harness 变成可训练对象，reward hacking、探索不足和灾难性遗忘等熟悉的失效模式也会随之出现。@DataChaz（51 次点赞，14 条回复，3,577 次浏览，60 次收藏）把这种运维层面的痛点串了起来：真正的失败往往发生在外围 harness，而不是模型本身。构建者目前的应对方式，是加入类型化组件、留出 gates 和更严格的 eval 层。这很值得投入去做，因为这种挫败感反复出现在发布帖、研究总结和工作流演示中。
通用 agents 依然抓不住领域约定和公司上下文¶
严重程度：高。spring-boot-skills 仓库由 @sivalabs（29 次点赞，1,057 次浏览，42 次收藏）提及，其开篇就在抱怨 AI coding agents 会臆造过时的 Spring Boot 模式，并忽视项目约定。@tom_doerr（17 次点赞，2,125 次浏览，23 次收藏）指向了 altimate-code，其卖点是：通用 coding agents 可以编辑 SQL 文件，却并不能真正理解现代数据栈。@coreyganim（163 次点赞，24 条回复，9,686 次浏览，385 次收藏）则把“second brain as a service”描述为一门生意，因为公司仍然需要先把自己的上下文整理好，agents 才能利用它；一条回复还明确指出，受监管行业依然很难推进，原因是隐私顾虑。如今团队的应对方式，是编写领域 skills、增加检索层，或者把工作限制在监管较少的环境里。这很值得去做，因为信息流里既有明确痛点，也有多个彼此独立的解决尝试。
能处理资金的 agents 仍需要更强的安全与信任边界¶
严重程度：高。@circle（158 次点赞，16 条回复，6,597 次浏览）把 guardrails 和明确权限作为 Agent Stack 的一等组成部分来推广，这说明控制问题并非附加项，而是核心问题。@HermesAgentTips（33 次点赞，2 条回复，2,341 次浏览，15 次收藏）则围绕 Stripe 集成提出了一个更令人不安的问题——你究竟会信任自己的 agent 自主购买什么？——而被引用的 Nous 帖子给出的回答是可配置的安全限制。@genrih99999（18 次点赞，2 条回复，298 次浏览）又把信任问题往下推进了一层：如果 agents 不能在不暴露私有记录的前提下证明自己的信誉，那么只有钱包还不够。当前的权宜模式已经很清楚：支出上限、策略检查、proof surfaces，以及围绕高风险动作的人类审核。这看起来很值得建设，因为需求是明确的，而现有控制仍然碎片化。
3. 大家希望存在什么¶
可移植、可验证的 skill 工件¶
人们想要的不是更多泛化 prompting，而是那种能够一次编写、可验证、并可跨工具复用的 skill 工件。@mattpocockuk（277 次点赞，21 条回复，11,088 次浏览，221 次收藏）提供了一种具体的 skill 写作技巧，agent-skills 展示了跨多种 agent 环境的生命周期打包方式，而 SkillOpt 则描述了如何在留出验证门之后优化一个 best_skill.md。实际需求已经很明确：构建者希望流程知识和领域知识在模型切换、工具变更后依然保留下来。机会：直接。
面向 agents 的安全金融控制平面¶
商业主题中最强烈的愿望，并不只是“让 agents 能付款”。而是“让 agents 在受约束的条件下付款、以程序化方式发现服务，并暴露清晰的权限边界”。@circle（158 次点赞，16 条回复，6,597 次浏览）和 Circle 的 Agent Stack 发布帖 通过钱包、策略控制、服务发现和 CLI 动作，把这一需求说得很明确；与此同时，@HermesAgentTips（33 次点赞，2 条回复，2,341 次浏览，15 次收藏）则把尚未解决的问题概括为：哪些购买行为应该允许完全自主？这是一个实际而紧迫的需求。机会：直接。
面向真实业务、兼顾隐私的公司大脑¶
@coreyganim（163 次点赞，24 条回复，9,686 次浏览，385 次收藏）描述了一门围绕整理公司上下文、让 AI 真正能在其上运作的服务生意；回复则立刻把焦点推向金融和医疗场景中的隐私问题。同样的底层需求也出现在像 altimate-code 这样的领域专用 harness 中：团队想要的是既能理解内部上下文、又不会泄露它，也不会把它粗暴压扁成通用 prompts 的 agents。这既是务实需求，也具有竞争性，因为已有多个构建者正朝着同一类供给的相邻版本收敛。机会：竞争型。
无需完全披露数据即可验证的 agent 声誉¶
AgentProof 的演示和网站都指向一种需求：agent 信任原语应该只暴露阈值证明，而不是完整日志、客户名单或 prompt 历史。@genrih99999（18 次点赞，2 条回复，298 次浏览）将其概括为“Know Your Agent”，而 AgentProof.org 则单独将 agents 的公开信任注册表和验证状态作为定位。这个方向仍然很早，但需求轮廓已经清晰可见。机会：愿景型。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Flue | 框架 | (+) | 可持久运行的 TypeScript harness，支持工作流、自主 agents、skills、sandboxes、subagents 和 channels | 仍处于 Beta；回复中也有人质疑“零锁定”到底有多真实 |
| SkillOpt | Skill 优化器 | (+) | 将 best_skill.md 视为可训练状态，支持留出验证和跨 harness 迁移 |
需要额外的训练 / eval 纪律，而不是一次性写完 skill |
| agent-skills | Skill 包 | (+) | 编码了 spec-plan-build-test-review-ship 工作流，并支持多种 agent 环境 | 仍依赖插件 / 配置工作，以及严格验证 |
| spring-boot-skills | 领域 skill 包 | (+) | 捕捉项目约定和现代 Spring Boot 模式，弥补通用 agents 的缺口 | 局限于 Spring Boot，仍需本地适配 |
| altimate-code | 数据工程 harness | (+) | 确定性 SQL 分析、lineage、dbt skills、数仓内省和本地可观测性 | 高度专用于数据团队，而非通用软件工作 |
| Circle Agent Stack | 支付基础设施 | (+) | 钱包、marketplace、CLI、nanopayments 和明确的权限控制 | 需要策略配置，且仍体现出早期 agent-commerce 栈的复杂性 |
| Hermes Agent + Stripe skills | 支付 skill 层 | (+/-) | 让 agents 能购买 API 和开通 SaaS，并带有可配置限制 | 信任边界仍未解决；即便支持者也在追问哪些支出该交给自主执行 |
| GLM-5.2 on OpenRouter | 模型 | (+/-) | 公开定位于长周期 coding-agent 工作，支持 1M-token 上下文 | 数据集中的证据大多仍停留在发布层面，回复也要求更强的 benchmark 证明 |
| Linear software factory flow | 方法 / 工作流 | (+) | 在一个从 issue 到修复的闭环中展示分诊、调查、编码和评审 | 数据集展示的是流程界面，而不是对失败场景的深入运营细节 |
总体来看，大家对专用层持积极态度，对泛化自主性则更为复杂。最清晰的迁移趋势，是从“只要给模型写 prompt 就行”转向类型化框架、领域 skill 包、检索 / 上下文层，以及明确的 eval gates。竞争压力同时出现在两个方向：skills 正在变成可安装产品，而支付与信任层则正在成为围绕这些 skills 的经济控制平面。
5. 大家在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Flue | @FredKSchott | 面向自主 agents、工作流、skills 和 channels 的框架 | 团队需要可持久运行的 harness，而不是一次性的 agent 脚本 | TypeScript、sandboxes、skills、tools、subagents | Beta | 推文, 仓库 |
| Circle Agent Stack | @circle | 面向 agents 的钱包、marketplace、CLI 和支付栈 | Agents 需要受策略约束的资金流转和服务发现 | USDC、Gateway、CLI、marketplace、skills | 已发布 | 推文, 博客 |
| three.ws | @nichxbt | 创建、部署并变现 3D AI agents | 具身 agents 仍缺乏打包好的产品界面和支付层 | Three.js、glTF、Solana、EVM、x402、MCP、WebXR | Beta | 推文, 网站 |
| altimate-code | @tom_doerr | Agentic 数据工程 harness | 通用 coding agents 不理解 dbt、数仓、SQL lineage 或 FinOps | SQL 解析器、dbt skills、数仓连接器、tracing | 已发布 | 推文, 仓库 |
| agent-skills | @sharbel | 面向 coding agents 的流程 skill 包 | 团队希望把高级工程师工作流编码进 agents | Markdown skills、斜杠命令、多工具安装 | 已发布 | 推文, 仓库 |
| spring-boot-skills | @sivalabs | Spring Boot 专用 skill 库 | Java 团队需要遵循框架约定的 agents | Claude skills、Spring Boot 模式、MCP Java 生态 | 已发布 | 推文, 仓库 |
| Bottega | @ChrisShort | 面向工程团队的多 agent 编排工具 | 团队需要一个可复用、有人在环的 agent 交付闭环 | React、Vite、Express、SQLite、Claude Code、Codex、OpenCode | Beta | 推文, 仓库 |
| Hermes manim-video skill | @IBuzovskyi | 一条视频生成流水线，由 agent 编写代码、渲染场景并拼接 MP4 输出 | 团队想要解说视频和演示，而不是依赖单一黑盒视频 API | Python、Manim CE、LaTeX、ffmpeg | 已发布 | 推文, 技能文档 |
反复出现的构建模式已经很清楚：与其打造一个通用超级 agent，人们更倾向于发布狭窄的 harness，把某个工作流、某个领域，或者某种经济边界编码进去。Flue、Bottega 和 Linear 对软件交付闭环的建模方式各不相同，但三者都默认：围绕模型，规划、实施、评审和恢复都需要明确结构。
领域 skill 包的构建者是在回应真实痛点。agent-skills 打包了通用工程生命周期，spring-boot-skills 打包了 Java 特定约定，而 altimate-code 打包了通用 coding agents 通常缺乏的数据工程智能。这是一个强信号，说明 skills 正在成为沉淀团队知识、又无需重训模型的首选方式。
最有辨识度的商业构建模式，则是给 harness 加上资金能力和具身化。Circle Agent Stack 把支付和服务发现变成了核心原语；three.ws 则把 avatar 创建、语音、WebXR 和按次聊天付费经济整合成一个可部署的 agent 界面。Hermes 的 manim-video skill 展示的是另一种相关模式：不是调用单一推理 API，而是让 agent 操作一整套工具链来产出最终工件。
6. 新动态与值得关注的内容¶
面向 agents 的代码驱动视频生成¶
@IBuzovskyi 展示了（62 次点赞，3 条回复，5,185 次浏览，115 次收藏）Hermes Agent 通过编写 Python、渲染 Manim 场景、拼接片段，并可选加入音频来生成视频。公开的 manim-video 技能文档 确认了完整流程为 PLAN -> CODE -> RENDER -> STITCH -> AUDIO -> REVIEW，这表明一部分“创意型” agent 工作正在转向完整工具链执行，而不再只是单次调用媒体 API。
长上下文开源编码模型仍在持续被讨论¶
@OpenRouter 宣布了（197 次点赞，5 条回复，7,283 次浏览，22 次收藏）将 GLM-5.2 定位为一个适合长周期 coding-agent 工作的模型，支持 1M-token 上下文窗口。OpenRouter 模型页面 补充了关于可用性和使用方式的产品层背景，而一条回复随即要求给出 DeepSWE 方面的证据，这表明模型发布如今不再主要按原始规模评判，而是看它们在 coding-agent evals 中的实际表现。
7. 机会在哪里¶
**+++］ 已验证的垂直领域技能平台** — 证据出现在第 1、2、4 和 5 节。构建者正在将工程流程封装到 ［agent-skills、spring-boot-skills 中的框架约定，以及 altimate-code 中的数据团队知识，而 SkillOpt 则展示了如何通过留出验证来改进这些工件。这个机会很强，因为痛点在反复出现，解决方案形态也在收敛。
**+++］ 带有支出控制的代理商业化** — ［@NousResearch、@circle 和 @HermesAgentTips 都指向同一个缺口：agents 在经济上越来越有行动能力，但仍然需要钱包、marketplaces、策略限制和审批边界。这一需求是即时的、务实的，而且已经吸引到严肃的平台投资。
[++] 私有信任证明与 agent 声誉层 — AgentProof 的阈值证明框架和公开信任注册表，为 marketplace 准入以及更高风险的 agent 工作提供了一条可信路径，同时无需完整披露 prompts、客户或内部日志。这个信号弱于 skills 和支付主题，但它与当天更广泛的证明、guardrails 和经济信任议题直接相连。
**+］ 面向中小企业的公司上下文服务** — ［@coreyganim 描述了一门围绕整理公司知识供 AI 使用的直接生意，而关于隐私的回复说明了为什么这类需求会持续存在。这仍是一个正在形成的机会：需求显而易见，但解决空间很可能会拥挤，而且对合规高度敏感。
8. 要点总结¶
- harness 正在成为产品本身，而不只是包装层。 Flue、Bottega、Linear、HarnessX 和 SDLC 白皮书都把结构、恢复和评估视为围绕模型的真正差异化因素。（来源）
- Skills 现在已成为可复用 agent 行为的主要打包格式。 当天最强的构建者工件是 skill 仓库、skill 编写建议，以及 skill 优化系统，而不是原始 prompt 线程。（来源）
- Agent 支付正在从概念走向技术栈。 Nous Stripe 黑客松、Circle Agent Stack 和 Hermes payment skills 的组合表明，经济行动能力正在成为一个明确的构建目标，但前提始终是明确的安全限制和权限。（来源）
- 信任正通过 proofs、gates 和 thresholds 来表达。 无论语境是 HarnessX 验证、SDLC guardrails，还是 AgentProof 基于私有记录给出的公开声明，信息流都更偏好可衡量的控制界面，而非模糊的治理口号。（来源）