Twitter AI Agent - 2026-08-13¶
1. 人们在讨论什么¶
1.1 运行框架工程，成了官方产品发布本身 (🡕)¶
至少有 6 个高信号项目，把运行框架工程本身当成产品表面，而不是背景胶水。讨论已经从昨天关于循环和验证的抽象，推进到具体的运行时、公开仓库、课程内容和架构说明：DeepSeek 发布了官方运行框架，Arcee 开源了一个长时任务替代方案。多位实践者则把智能体质量描述成围绕插件、日志、worker 和外置状态的系统问题。
@deepseek_ai 宣布了（5,681 个赞、288 条回复、346,404 次浏览、1,695 次收藏）DeepSeek Harness v0.1，这是一个开发者预览、采用 MIT 许可的运行框架，其中模型、工具、技能、会话、沙箱、文件系统、循环、编排和 UI 都是插件。公开的 仓库 重复了同样的主张，称该项目由 Cordis 驱动，并提醒开发者在预览期内会遇到破坏兼容性的变更。
@akshay_pachaar 解释了（222 个赞、10 条回复、21,386 次浏览、249 次收藏）为什么这条插件边界很重要：上下文组装可以在不 fork 框架的前提下修改，依赖是声明式的，不必手工排顺序，而会话日志会记录 system prompt、tool call、subagent 调度和 context injection。最有价值的一条回复则直接点出了取舍：插件化行为比 fork 更易配置，但也更难通过静态 diff 看清。
@khushiirl 传播了（233 个赞、12 条回复、7,210 次浏览、295 次收藏）《Learn Harness Engineering》，附带截图展示了一组关于失败模式的课程序列，而读者对其中的问题早已不陌生：仓库是系统记录源、长任务中的连续性丢失、智能体过早宣布胜利，以及端到端测试。之所以重要，是因为当天最强的几次发布，已经是用一套共享的运行框架词汇来解读，而不是再讲提示词技巧。
@arcee_ai 发布了（197 个赞、14 条回复、71,294 次浏览、120 次收藏）nac，这是一个面向长时任务、采用 Apache-2.0 许可的运行框架。公开的 README 和 技术文章 表示，nac 通过让中央编排器分发全新的 worker，并让它们返回可保留的“episodes”，从而把临时 worker 上下文与持久状态分开；它还支持 MCP，并明确支持跨任务穿针引线式地串接线程。
讨论要点： 争论已经不再是智能体需不需要运行框架，而是运行框架到底必须暴露什么：可替换组件、模型可见日志、有边界的 worker，以及能跨运行保留下来、又不用拖着整段转录一起前进的状态。
与前日对比： 8 月 12 日让运行框架工程成为解释智能体质量的主导层。8 月 13 日则把这个主题推进成了已经出货的官方运行时、公开仓库，以及可被教授的课程体系。
1.2 技能成了智能体行为的主要分发层 (🡕)¶
第二簇讨论，聚焦于把 know-how 打包成可复用的技能、市场，以及斜杠命令表面。重心已经从一次性提示词，转向那些可以一次编写、公开发布、被他人导入，并在团队或工具之间携带的工作流。
@figma 宣布了（61 个赞、9 条回复、7,470 次浏览、26 次收藏），用户可以用 Figma 智能体创建技能，把它们发布到 Community、保存别人做的技能，并通过 / 命令运行。Figma 公开的 skills 文章 把技能描述为可复用的自然语言指令，并称它们可以与 connectors 协同工作，而且很快也会接入 Figma 的 MCP server；回复则立刻要求自动触发，以及支持从 Figma 之外加载技能。
@ArchiveExplorer 声称（33 个赞、3,155 次浏览、35 次收藏）已经把 27 份官方 AI lab 文档变成了 22 个可安装技能，让智能体只需安装一次，就能直接套用 Anthropic、OpenAI、Google 和 Microsoft 的指导。即便推文没有展开更多仓库元数据，真正传播开的点仍然是方法可移植性：上下文工程、评估循环、运行框架模式、MCP 迁移，以及零信任规则，都被打包成了可运行行为，而不只是阅读材料。
@dannolan 展示了（91 个赞、13 条回复、9,509 次浏览、91 次收藏）一个智能体，如何通过 MCP 调用市场去找产品，再回报这些产品到底好不好。回复补上了落地细节：浏览不需要登录，但发消息仍然需要 Facebook 会话，而输出太啰嗦的问题，用户现在仍主要靠提示词来调。
@heyemilyx 认为（12 个赞、2,860 次浏览、12 次收藏），桌面智能体真正的差异化，可能不是某一个模型，而是共享记忆，因为它能让用户在 GPT、Claude 或 Kimi 之间切换时，不用把整个工作流从头再来。这正好契合了更大的封装趋势：真正有黏性的层，越来越像是可复用的工作流和记忆表面，而不是底层模型本身。
讨论要点： 人们已经不只是想在单一客户端里写出更好的提示词。他们想要的是可共享的技能、社区发现、由 MCP 中介的分发，以及能在切换模型之后继续存活的记忆层。
与前日对比： 8 月 12 日已经把插件和技能指向了封装原语。8 月 13 日则把这个模式扩展到了创作者工具、社区分发、市场使用，以及跨模型记忆的主张。
1.3 智能体开始被当作有监督者、账本和全流程任务的队友 (🡕)¶
第三个主题，把智能体进一步从“copilot”的框架推开，更接近拥有赞助人、审批、例行任务和公开记录的持久 worker。最强的几个例子，关心的已经不是代码生成，而是判断、委派，以及如何在多步骤中保持工作状态一致。
@kunchenguid 报告称（1,844 个赞、121 条回复、104,393 次浏览、213 次收藏），Grok 4.6 在一次真实的多智能体工作日里，作为编排器表现得异常出色：该合并时合并、该升级时升级，还能阻止 worker 智能体过度工程化。但同一条帖子也变成了定价抱怨，因为一天里大多还是单线程的使用，就耗尽了一周的 SuperGrok Heavy 配额；Elon Musk 的回复“在看了”，让这个痛点继续停留在视野里。
@iamlukethedev 认为（130 个赞、14 条回复、4,971 次浏览、64 次收藏），Hermes 不该直接拿来和 Claude Code 或 Codex 比，因为它高了一层：负责分诊工单、委派工作、处理评审反馈、更新 Jira、发起审批，并把结果路由到聊天应用。帖子列出的功能清单，也让这个主张变得具体：持久记忆、可复用技能、浏览器和电脑使用、后台子智能体、审计轨迹、密钥保险库，以及成本跟踪。
@doodlestein 介绍了（89 个赞、18 条回复、4,164 次浏览、48 次收藏）ASImposium，这是一个面向智能体及其人类赞助人的公共科学账本。公开的 站点 和 仓库 表示，这套系统把私密 workshop 工作和公开的 append-only ledger 分开，让模型执行不落在服务器上，并试图靠“公开主张必须经过验证器”来阻止“自我认证”。
@championswimmer 描述了（197 个赞、10 条回复、11,837 次浏览、177 次收藏）组织层面的同一转向：团队正在艰难地从 copilot 式编程，迁移到“jira-to-agent-to-automerge-PR”系统，因为许多工程师仍然按单次 API 调用来思考，而不是按确定性预处理、沙箱 VM 和后处理 hook 来思考。
讨论要点： 理想终局并不是“一个会写代码的 AI”。人们想要的是一套能在人类检查点之间承担责任、同时让人类保有批准、重定向或撤销权的智能体系统。
与前日对比： 8 月 12 日已经把编程智能体当成长时运行的操作员。8 月 13 日则进一步把这种定位推向了队友隐喻、公开科研账本，以及围绕配额、认证流程和编排开销的实际抱怨。
2. 令人困扰的问题¶
配额、上下文上限和人工步骤，会打断原本不错的编排¶
最直接的困扰是：智能体现在已经能做出不错的判断，但围绕它的产品在真实工作里还是会掉链子。@kunchenguid 报告称（1,844 个赞、121 条回复、104,393 次浏览、213 次收藏），Grok 4.6 作为编排器的判断力非常好，却仍然在一个工作日里就啃光了一周的顶级配额；还有一条回复说，用户不得不再搭配 Cursor，才能换来更高的额度。@doodlestein 随后补充（25 个赞、5 条回复、1,422 次浏览、13 次收藏），启动一个项目依然意味着要去浏览器里手动做 Google Cloud 认证这类杂务，而回复则表示，哪怕有 computer use，最后往往还是得靠人手点几下确认。当前的应对方式，是混搭多种产品、把设置过程外包给浏览器自动化方案，并让人类留在最后一公里。值得构建程度：高。
团队仍不知道运行框架该止步于哪里、模型又该从哪里开始¶
第二个困扰更偏概念层，但它表现出来时，却用了非常操作性的语言。@championswimmer 描述了（197 个赞、10 条回复、11,837 次浏览、177 次收藏），很多工程师仍觉得主工具就是一次 LLM API 调用，即便真实工作明明需要预处理、后处理、确定性解析器，以及沙箱 VM。那条讨论串还表示，许多团队仍卡在 CRUD 时代的后端思维里；另一条回复则警告，如今非技术管理者生成代码的速度，已经快过真正要维护这些代码的人去评估爆炸半径的速度。这不是口味之争，而是架构和责任归属错位。值得构建程度：高。
“人在回路中”的说法，还不等于真正的决策权¶
第三个困扰是，监督话语已经跑在控制设计前面。@omarsar0 强调了（12 个赞、1 条回复、1,374 次浏览、21 次收藏）Harness-IF：它最醒目的结论是，一旦把“模型本来就会做到的巧合”剥离掉，并改用执行证据来评分，许多所谓的指令遵循提升就会消失。另一个互动量较低、但很有价值的补充来自 @Snowizzie，他 认为（1 个赞、216 次浏览、1 次收藏），如果签名密钥还握在同一套软件环境里，那么人类点击一下“approve”，并不等于真正拥有决策权。
人们现在的应对方式，是增加证据闸门、把关键权限拆到硬件之外，并采用基于执行结果的评估，而不是只信成功叙述或提示词摆放位置。值得构建程度：高。
3. 人们期望的功能¶
能让工作流跨模型切换继续存活的模型无关记忆¶
最清晰的实际需求，是有一层工作流能够在所选模型变化后依然继续存在。@heyemilyx 认为（12 个赞、2,860 次浏览、12 次收藏），真正的价值在共享记忆，因为它能让人们在 GPT、Claude 和 Kimi 之间切换时不用重来；而 @iamlukethedev 则把（130 个赞、14 条回复、4,971 次浏览、64 次收藏）Hermes 定位成正是这样一层高于单个编程智能体的持久性、审批和协作层。这是一个直接需求：用户想要的是连续性和路由能力能活得比任何单一模型选择更久。机会：直接。
能跨工具迁移、并替你多做一步触发的技能市场¶
人们同样想要更容易发布、发现和触发的技能系统。@figma 宣布了（61 个赞、9 条回复、7,470 次浏览、26 次收藏）可以社区发布的技能，并支持用斜杠命令执行；回复则立刻要求自动触发，以及能从 Figma 外部加载技能。@ArchiveExplorer 展示了（33 个赞、3,155 次浏览、35 次收藏）这种可移植性的终局：27 份实验室手册被打包成了 22 个可安装技能；而 @dannolan 展示了（91 个赞、13 条回复、9,509 次浏览、91 次收藏）MCP 中介的发现流程，如今在实践里已经很有用。这是一个务实、但竞争越来越激烈的方向：需求很明显，但多个技能表面正在同时成形。机会：竞争型。
围绕编程智能体仍收不了尾的环节，补上更好的浏览器与认证自动化¶
另一个更窄、却很紧迫的需求，是稳妥处理那些仍会逃出终端的设置流程。@doodlestein 表示（25 个赞、5 条回复、1,422 次浏览、13 次收藏），启动项目最烦的部分，依然是手动在 Google Cloud 里把认证配置走完；回复还表示，即便已经有 computer-use 方案，有时还是得靠人偶尔点几下“yes”。这不是愿景问题，而是具体、反复发生的需求：人们想要浏览器技能、能理解认证流程的规划器，以及能把同一套设置杂务每次都跑完的控制台自动化。机会：直接。
能保留死胡同、而不是把它们埋进本地滚屏里的智能体协作公共账本¶
@doodlestein 提出了（89 个赞、18 条回复、4,164 次浏览、48 次收藏）ASImposium，想把它做成一个面向智能体和人类监督者的论坛，而公开的 站点 说，问题在于如今有能力的科研工作，往往死在本地运行框架历史里，其他智能体根本没法复用。这一诉求没有上面的工作流和认证需求那么务实，但感受非常真实：用户想要一种耐久、公开的多智能体研究记忆，既保留结果，也保留走过的死路。机会：愿景型。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| DeepSeek Harness | 智能体运行框架 / runtime | (+/-) | 万物皆插件的架构、开发者预览 Web UI、明确的社区 / 插件主题 | 仍处预览期，且已预告会有破坏性变更；插件与运行时之间的交互仍会带来调试问题 |
| nac | 长时运行框架 | (+) | 线程加 episode 设计、全新 worker、可保留的 episode、MCP 集成 | 工作流较新、搭建成本不低；编排器会在批量同步点等待 |
| Learn Harness Engineering | 课程 / 方法 | (+) | 把失败模式、状态、验证和测试整理成可复用课程 | 是教学资源，不是运行时；落地负担仍留给团队 |
| Grok 4.6 + MyFirstMate | 模型 + 编排工作流 | (+/-) | 在升级、合并和阻止过度工程上判断力强 | 顶级配额耗尽太快；重度使用下订阅经济性偏弱 |
| Hermes | 编排层 | (+/-) | 持久记忆、可复用技能、子智能体、审批、浏览器 / 电脑使用、审计轨迹 | 比单个编程任务更重更广；用户仍拿账单增长开玩笑 |
| Figma skills | 技能平台 / 设计智能体 | (+/-) | 技能可编写、发布、保存，并通过 / 运行；连接器和 MCP 也是核心叙事的一部分 |
用户仍想要自动触发，以及从 Figma 外部导入技能的路径 |
| MCP marketplace workflow | 集成模式 | (+) | 让智能体搜索市场并内联总结结果 | 某些后续动作仍需登录会话；不调 prompt 时输出可能过于冗长 |
整体满意度，集中出现在那些能把持久工作流状态与瞬时模型上下文分开的系统上。最让人满意的帖子，夸的是显式编排、保留下来的记忆，以及可复用技能；最主要的抱怨则是成本上限、预览版粗糙边角，以及浏览器 / 认证工作仍会从本来已经很高级的运行框架里漏出来。迁移压力正同时朝两个方向展开：一边是从提示词中心主义转向运行框架，另一边是从单模型锁定转向“记忆层稳定、底层模型可替换”的工作流。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| DeepSeek Harness | @deepseek_ai | 官方开源智能体运行框架，把模型、工具、会话、循环和 UI 都插件化 | 团队想替换控制表面时，不想每次都把整个框架 fork 一遍 | Cordis、插件架构、Node.js Web UI | 测试版 | 仓库, 帖子 |
| nac | @arcee_ai | 使用全新 worker 和持久 episode 的长时运行框架 | 一旦原始转录历史成了唯一记忆，长任务就会丢失意图 | 线程与 episode 编排、MCP、provider API | 测试版 | 仓库, 博客, 帖子 |
| GooeyPi | @LLMJunky | 面向 Pi 系智能体的 GUI 运行框架，带浏览器、语音、git、终端和自动化能力 | 本地模型用户想要更丰富的运行框架，不想不停切配置，也不想只能用纯 TUI | Pi / OMP / Prime Agent 生态、本地模型、浏览器、语音、git、终端 | 测试版 | 帖子 |
| ASImposium | @doodlestein | 面向智能体与赞助人的“workshop + ledger”科研协作系统 | 智能体研究消失在本地滚屏里，既无法共享死胡同，也缺乏评审状态 | 公共账本、绑定赞助人的智能体、Claude Code / Codex / Grok Build 集成 | RFC | 站点, 仓库, 帖子 |
| AI-lab docs skill pack | @ArchiveExplorer | 把官方实验室手册变成智能体可直接使用的可安装技能 | 团队不想反复重读最佳实践，而想把它们编码成可重复的工作流 | Markdown 技能、实验室文档、可安装智能体工作流 | 已发布 | 帖子 |
DeepSeek Harness 和 nac，是当天最清晰的一种构建模式：两者都把持久状态外置，并把主对话上下文视为一种应该被限制、可被检查、必要时可以丢弃的东西，而不是神圣不可动的核心。DeepSeek 更强调在同一个插件运行时里做到最大可替换性，nac 则更强调把编排与执行分开，只从 worker 手里保留紧凑的 episode。
GooeyPi 和 ASImposium 则指向第二种模式：构建者开始用更有主张的环境去包裹智能体系统，而不是任由它们停留在原始聊天界面里。GooeyPi 把本地智能体工作流打包成桌面风格 GUI，ASImposium 则试图为研究协作提供一个智能体优先的公共记录。两者的触发点是一样的：一旦智能体真的开始做事，团队要的就不只是把事做完，而是让多人能协调起来。
6. 新动态与亮点¶
Harness-IF 用数字说明了“指令遵循”里有多少其实只是巧合¶
@omarsar0 带出了（12 个赞、1 条回复、1,374 次浏览、21 次收藏）Harness-IF，这是一篇评估编程智能体在不同提示表面上指令遵循能力的论文。对实践者来说，最关键的不是准确率本身，而是：一旦评估剥离掉模型本来就会做的事，性能就会明显下降；同时，system prompt、项目文件和用户指令的影响，都比工具或技能说明更大。任何正在写 AGENTS.md、工具提示词或技能包的团队，都会被这件事直接影响。
智能体工程的五层词汇，有了一个清晰的公开图示¶
@dmokafa 发了一张（2 个赞、236 次浏览、3 次收藏）简洁的分类图，把 prompt、context、harness、loop 和 graph engineering 分成了不同层。它的互动量不高，但图本身异常有用，因为它给每一层都配上了非常具体的工作单位：一个 prompt、一个窗口、一次运行、一个目标，以及一整条工作流。
监督与权力的区别，成了更尖锐的安全边界¶
@Snowizzie 认为（1 个赞、216 次浏览、1 次收藏），即便一个 LangGraph 流程结构再清楚，只要签名密钥还掌握在同一套软件系统里，它就不是真正的安全边界。这条信号在数量上并不主导时间线，但它让当天更大范围的转向变得更锋利：人们越来越在意把权限外置、把关键决策与硬件分离，并让审批建立在证据上，而不是停留在界面戏法上。
7. 机会在哪里¶
[+++] 带显式状态、日志和权限边界的长时控制平面 —— DeepSeek Harness、nac、Championswimmer 关于企业扩散失败的讨论串，以及“监督不等于权力”的示意图，都指向同一个缺口：团队需要一种运行时，能够把瞬时 worker 上下文与持久任务状态拆开，让模型可见事件保持可检查，并让敏感动作最终落在真正的审批边界上，而不是软件层的表演。
[++] 可移植的技能打包与市场分发 —— Figma skills、ArchiveExplorer 的实验室文档技能包，以及 Dannolan 的 MCP 市场演示，都说明人们想要的是那种“写一次、能被社交传播、能跨工具复用”的智能体行为。真正的机会，不只在发布和同步，还在自动触发、兼容性，以及评估一个技能到底改变了什么。
[+] 浏览器原生的项目设置与认证自动化 —— Doodlestein 对 Google Cloud 设置的抱怨，以及回复里关于 computer use 仍然需要点“yes”的说法，都表明大量摩擦如今发生在终端之外。这里有空间去做能安全穿越管理后台、认证流程和重复设置表面的智能体，而不是让每个新项目都再来一遍手工清单。
8. 要点总结¶
- 运行框架如今是在作为产品竞争，而不只是作为想法。 DeepSeek 和 Arcee 在同一天都发布了面向长时智能体工作的开源运行时，只是它们对状态、控制和上下文漂移给出了不同答案。(DeepSeek, nac)
- 技能正在成为智能体能力的耐久单位。 Figma 把技能带进了社区发布，ArchiveExplorer 把实验室手册打包成可安装工作流，而 MCP 市场用法则说明，智能体已经在通过工具表面“购物”，而不是等待定制集成。(Figma, ArchiveExplorer, dannolan)
- 最难的阻塞点，往往不是模型质量，而是围绕模型缺失的那套系统。 Championswimmer 关于企业扩散的讨论、Doodlestein 对控制台设置的抱怨，以及 Harness-IF 的结果，都在指向同一个问题：团队仍然需要更好的流水线、评估和设置工具。(championswimmer, doodlestein, omarsar0)
- 判断力很值钱，但没有成本与权限控制也不够。 Grok 4.6 因编排判断力而受赞赏，但配额耗尽限制了采用；与此同时，互动量较低的安全讨论则坚持认为，只有当权力真的从软件路径中分离出来，审批才算数。(kunchenguid, Snowizzie)