跳转至

Twitter AI Agent - 2026-08-13

1. 人们在讨论什么

1.1 Harness 工程已从幕后基础设施变成官方产品发布(🡕)

至少有六条高信号信息把 harness 工程本身当作产品界面,而不再只是后台胶水。讨论也从昨天围绕循环与验证的抽象话题,转向了具体的运行时、公开仓库、课程内容和架构解析:DeepSeek 发布了官方 harness,Arcee 开源了一个面向长周期任务的替代方案,还有多位实践者把 agent 质量定义为一个系统问题,核心在于插件、日志、worker 和外置状态。

@deepseek_ai 宣布(5,681 个赞、288 条回复、346,404 次浏览、1,695 次收藏)发布了 DeepSeek Harness v0.1:这是一个开发者预览版、采用 MIT 许可证的 harness,其中模型、工具、技能、会话、沙箱、文件系统、循环、编排和 UI 全都以插件形式存在。公开的 仓库 重申了这一说法,称该项目由 Cordis 驱动,并提醒预览期间预计会有破坏兼容性的改动。

@akshay_pachaar 解释了(222 个赞、10 条回复、21,386 次浏览、249 次收藏)解释了这种插件边界为何重要:上下文组装方式可以在不 fork 框架的前提下修改,依赖关系通过声明定义而非手动串接,会话日志则会记录系统提示词、工具调用、子 agent 调度和上下文注入。最有价值的一条回复直接点出了权衡:插件化行为比 fork 更易配置,但也更难通过静态 diff 审查。

展示 DeepSeek Harness 仓库卡片,显示公开发布 deepseek-ai/deepseek-harness 以及早期 star 增长势头

@khushiirl 流传开来(233 个赞、12 条回复、7,210 次浏览、295 次收藏)提到《学习 Harness 工程》,配图展示了一组关于失败模式的课程内容。这些问题,生产环境中的 agent 从业者早已十分熟悉:把仓库当作事实记录源、长任务中的连续性丢失、agent 过早宣布成功,以及端到端测试。这之所以重要,是因为当天最受关注的几项发布,都是通过一套共享的 harness 词汇来理解,而不是靠提示词技巧来解读。

Learn Harness Engineering 课程页面,展示关于为什么 agents 会失败、状态、连续性和验证的课程内容

@arcee_ai 发布了(197 个赞、14 条回复、71,294 次浏览、120 次收藏)提到 nac:一个面向长周期任务、采用 Apache-2.0 许可证的 harness。公开的 README 和 技术写作 表示,nac 通过中央编排器调度全新的 worker,把临时 worker 上下文与持久状态分离;worker 返回可保留的“episodes”,同时支持 MCP,并在任务之间显式进行线程编织。

讨论洞察: 争论的重点已不再是 agent 是否需要 harness,而是 harness 必须暴露什么:可替换组件、模型可见日志、有边界的 worker,以及能在运行结束后继续保留、又不会把整段对话历史一并拖着走的状态。

与前一天对比: 8 月 12 日让 harness 工程成为解释 agent 质量的主导框架。到 8 月 13 日,这一主题进一步落实为已发布的官方运行时、公开仓库和可教学的课程体系。

1.2 技能成为 agent 行为的主要分发层(🡕)

第二个讨论集群聚焦于把经验封装为可复用技能、市场和斜杠命令界面。方向正在从一次性提示词,转向可以一次编写、公开发布、导入使用,并在团队或工具之间迁移的工作流。

@figma 宣布(61 个赞、9 条回复、7,470 次浏览、26 次收藏)表示,用户可以用 Figma agent 创建技能,将其发布到 Community,保存他人的技能,并通过 / 命令运行。Figma 公开的 skills 帖子 把技能描述为可复用的自然语言指令,并称其可与连接器配合使用,未来还将接入 Figma 的 MCP server;回复区很快就提出了自动调用,以及从 Figma 外部加载技能的需求。

@ArchiveExplorer 声称(33 个赞、3,155 次浏览、35 次收藏)称,已将 27 份官方 AI 实验室文档转成 22 个可安装技能,让 agent 通过一次安装就能应用 Anthropic、OpenAI、Google 和 Microsoft 的指导原则。即便推文没有展开更多仓库元数据,真正传播开来的重点仍是方法论的可迁移性:上下文工程、评测循环、harness 模式、MCP 迁移和零信任规则,都被封装成可执行行为,而不只是阅读材料。

@dannolan 展示了(91 个赞、13 条回复、9,509 次浏览、91 次收藏)展示了一个 agent 通过 MCP 使用市场来寻找商品,并回报这些商品是否值得购买。回复补充了关键的实现细节:浏览无需登录,但发消息仍需要 Facebook 会话;输出详细程度仍需由用户在提示词中自行调节。

@heyemilyx 认为(12 个赞、2,860 次浏览、12 次收藏)认为,桌面 agent 真正的差异化因素也许不是某个单一模型,而是共享记忆,因为它能让用户在 GPT、Claude 和 Kimi 之间切换时无需重启工作流。这也符合更大的封装趋势:越来越有黏性的层,正变成可复用的工作流和记忆界面,而不是底层模型。

讨论洞察: 人们要的已经不只是某个客户端里更好的提示词,而是可分享的技能、社区发现机制、经由 MCP 的分发渠道,以及能在切换模型后继续保留的记忆层。

与前一天对比: 8 月 12 日已经把插件和技能视为封装原语。8 月 13 日则把这一趋势进一步延伸到了创作者工具、社区分发、市场使用,以及跨模型记忆的相关主张。

1.3 Agent 被塑造成有监督者、账本和端到端杂务的队友(🡕)

第三个主题进一步把 agent 从“副驾驶”叙事推向了拥有发起人、审批、例行流程和公开记录的持久化 worker。最有代表性的案例,关注点不再是代码生成本身,而是判断、委派,以及如何在多步骤流程中保持工作状态一致。

@kunchenguid 报道(1,844 个赞、121 条回复、104,393 次浏览、213 次收藏)称,Grok 4.6 在真实的多 agent 工作日里作为编排器表现异常出色:该合并时会合并,需要升级处理时会升级处理,也能阻止 worker agent 过度设计。但同一条帖子也变成了对定价的抱怨,因为一天几乎单线程的使用就耗尽了一周的 SuperGrok Heavy 配额;Elon Musk 回复“Looking into it”,让这一痛点持续留在视野中。

@iamlukethedev 认为(130 个赞、14 条回复、4,971 次浏览、64 次收藏)认为,Hermes 不应直接拿来与 Claude Code 或 Codex 比较,因为它高出一层:负责分诊工单、委派工作、处理评审反馈、更新 Jira、请求审批,并把结果路由到聊天应用。帖子列出的功能也让这一定位更加具体,包括持久记忆、可复用技能、浏览器和计算机操作、后台 subagent、审计轨迹、密钥保管库和成本跟踪。

@doodlestein 介绍了(89 个赞、18 条回复、4,164 次浏览、48 次收藏)提到 ASImposium:一个面向 agent 及其人类发起人的公开科学账本。公开的 网站 和 仓库 表示,该系统把私有 workshop 工作与公开的只追加账本分开,模型执行不在服务器上进行,并试图通过要求公开主张必须经过验证者把关,来防止“自我认证”。

@championswimmer 描述了(197 个赞、10 条回复、11,837 次浏览、177 次收藏)展现了同一转变在组织层面的体现:团队正努力从副驾驶式编码转向“jira-to-agent-to-automerge-PR”系统,因为许多工程师仍以单次 API 调用来思考问题,而不是从确定性预处理、沙箱 VM 和后处理钩子的角度来设计。

讨论洞察: 目标终局不是“一个会写代码的 AI”,而是一个能在人类检查点之间承担责任的 agent 系统,同时人类依然保有批准、重定向或撤销工作的权力。

与前一天对比: 8 月 12 日已经把编码 agent 视为长时间运行的操作者。到了 8 月 13 日,这一趋势进一步延伸到队友隐喻、公开研究账本,以及围绕配额、认证流程和编排开销的现实抱怨。


2. 什么让人沮丧

配额、上下文限制,以及破坏原本良好编排的手动步骤

最直接的挫败感在于,agent 现在已经能做出不错的判断,但周边产品在真实工作中仍会失灵。@kunchenguid 报道(1,844 个赞、121 条回复、104,393 次浏览、213 次收藏)称,Grok 4.6 在编排判断上表现极佳,却仍在一个工作日内耗尽了一周的顶级配额;一条回复说,用户不得不用 Cursor 来补足更高额度。@doodlestein 跟进了(25 个赞、5 条回复、1,422 次浏览、13 次收藏)指出,启动项目仍意味着要处理只能在浏览器里完成的杂务,比如 Google Cloud 认证;回复则表示,计算机操作仍需要人工确认点击。人们目前的应对方式,是混搭不同产品、把设置工作外包给浏览器自动化方案,并在人类参与下完成最后一公里。值得构建程度:高。

团队仍不知道 harness 应该止于何处,模型又该从何处开始

第二类挫败感更偏概念层面,但表达方式非常操作化。@championswimmer 描述了(197 个赞、10 条回复、11,837 次浏览、177 次收藏)提到,一些工程师仍把一次 LLM API 调用当成主要工具,即便真实工作负载需要的是预处理、后处理、确定性解析器和沙箱 VM。同一讨论串还说,许多团队仍卡在 CRUD 时代的后端思维里;一条回复则警告,非技术管理者如今生成代码的速度,可能已经超过需要维护这些代码的人评估其影响范围的速度。这不是审美层面的争论,而是架构与问责机制的不匹配。值得构建程度:高。

“人在回路中”的说法还没有真正落实为控制权

第三类挫败感在于,监督措辞已经跑在控制设计前面。@omarsar0 强调了(12 个赞、1 条回复、1,374 次浏览、21 次收藏)提到 Harness-IF,这项工作的核心结论是:一旦排除偶然重合,并改用执行证据来评估,许多“指令遵循”的优势就会消失。另一个信号较弱但有用的补充来自 @Snowizzie,后者 认为(1 个赞、216 次浏览、1 次收藏)指出,如果同一个软件环境仍持有签名密钥,那么人类点击“批准”并不等于真正拥有权力。

图示展示了策略检查、模拟、记忆审查和人工批准如何共同导向由硬件持有的最终签署决策

人们正在通过增加证据门槛、采用硬件隔离的授权,以及基于执行结果的评估来应对这一问题,而不是仅凭成功叙述或提示词摆放位置来建立信任。值得构建程度:高。


3. 人们希望出现什么

与模型无关的记忆层,让工作流在切换模型后仍能延续

最清晰的实际需求,是一个即使所选模型发生变化也能持续存在的工作流层。@heyemilyx 认为(12 个赞、2,860 次浏览、12 次收藏)指出,真正的价值在于共享记忆,因为它能让用户在 GPT、Claude 和 Kimi 之间切换时无需从头开始;而 @iamlukethedev 将其定位为(130 个赞、14 条回复、4,971 次浏览、64 次收藏)则把 Hermes 描述为恰好位于单个编码 agent 之上的那一层:负责持久化、审批和协调。这是一个直接需求:用户希望连续性和路由能力能独立于任何单一模型选择而存在。机会:直接。

能跨工具迁移的技能市场,并替你完成更多调用

人们还希望技能系统更易于发布、发现和触发。@figma 宣布(61 个赞、9 条回复、7,470 次浏览、26 次收藏)提到可发布到社区、并通过斜杠命令执行的技能;回复随即要求支持自动调用,以及从 Figma 外部加载技能。@ArchiveExplorer 展示了(33 个赞、3,155 次浏览、35 次收藏)通过把 27 份实验室手册打包成 22 个可安装技能,展示了可迁移性的终局;而 @dannolan 展示了(91 个赞、13 条回复、9,509 次浏览、91 次收藏)则说明,经由 MCP 的发现机制在实践中已经相当有用。这一方向很务实,但竞争也在迅速加剧:需求非常明确,而多个技能界面正同时成形。机会:竞争型。

更好的浏览器与认证自动化,补上编码 agent 仍无法顺利完成的环节

另一个范围较窄但很紧迫的需求,是可靠处理那些仍然逃离终端的设置流程。@doodlestein 表示(25 个赞、5 条回复、1,422 次浏览、13 次收藏)指出,启动项目最烦人的部分,依然是手动在 Google Cloud 中来回操作以配置认证;回复则表示,即使有计算机操作方案,仍偶尔需要点“是”确认。这是一个具体而非理想化的需求:人们想要的是浏览器技能、理解认证流程的规划器,以及可重复的控制台自动化,去完成每个新项目都会重新上演的那一套设置杂务。机会:直接。

面向 agent 协作的公开账本,保留死胡同,而不是把它们埋进本地滚动历史里

@doodlestein 提出了(89 个赞、18 条回复、4,164 次浏览、48 次收藏)将 ASImposium 描述为一个供 agent 和人类监督者使用的论坛;公开的 网站 则指出,问题在于,如今有价值的科学工作正死在本地 harness 历史中,其他 agent 无法复用。与前述工作流和认证需求相比,这一方向更偏理想型,但感受是明确存在的:用户想要一个持久、公开的多 agent 研究记忆,既保存成果,也保存走不通的路径。机会:理想型。


4. 正在使用的工具与方法

工具 类别 情绪 优势 局限
DeepSeek Harness Agent harness / 运行时 (+/-) 一切皆插件的架构;开发者预览版 Web UI;明确的社区/插件话题 仍处于预览阶段,且预计会有破坏兼容性的改动;插件与运行时之间的交互仍带来调试问题
nac 长周期 harness (+) 线程与 episode 设计;全新 worker;可保留 episodes;MCP 集成 工作流较新,设置开销较高;编排器会在批次同步点等待
Learn Harness Engineering 课程 / 方法 (+) 将失败模式、状态、验证和测试整理成可复用课程 这是教育内容,不是运行时;实现负担仍由团队承担
Grok 4.6 + MyFirstMate 模型 + 编排工作流 (+/-) 在升级处理、合并和阻止过度设计方面判断力强 顶级配额消耗过快;对重度用户而言,订阅性价比偏低
Hermes 编排层 (+/-) 持久记忆、可复用技能、subagent、审批、浏览器/计算机操作、审计轨迹 比单一编码任务更广也更重;用户仍会拿账单不断上涨开玩笑
Figma skills 技能平台 / 设计 agent (+/-) 技能可以创建、发布、保存,并通过 / 运行;连接器和 MCP 也是其能力叙事的一部分 用户仍希望支持自动调用,以及从 Figma 外部导入
MCP 市场工作流 集成模式 (+) 允许 agent 搜索市场并在流程内直接总结发现 部分后续操作仍需要登录会话;若不调提示词,输出可能过于冗长

总体来看,用户最满意的是那些把持久工作流状态与临时模型上下文分离开的系统。反响最好的帖子称赞的是显式编排、可保留记忆和可复用技能;主要抱怨则集中在成本上限、预览版的粗糙体验,以及浏览器/认证工作仍会从原本复杂的 harness 中漏出来。迁移压力正同时朝两个方向显现:一是从以提示词为中心的工作转向 harness,二是从单模型锁定转向可在稳定工作流之下替换模型的记忆层。


5. 人们在构建什么

项目 构建者 功能 解决的问题 技术栈 阶段 链接
DeepSeek Harness @deepseek_ai 官方开源 agent harness,将模型、工具、会话、循环和 UI 全部插件化 团队希望更换控制界面而无需 fork 整个框架 Cordis、插件架构、Node.js Web UI Beta 仓库, 帖子
nac @arcee_ai 使用全新 worker 和持久 episodes 的长周期 harness 当原始对话历史成为唯一记忆时,长任务会丢失意图 线程与 episode 编排、MCP、provider APIs Beta 仓库, 博客, 帖子
GooeyPi @LLMJunky 面向 Pi 系列 agent 的 GUI harness,支持浏览器、语音、git、终端和自动化功能 本地模型用户想要更丰富的 harness,而不必频繁切换配置,也不必局限于纯 TUI Pi / OMP / Prime Agent 生态、本地模型、浏览器、语音、git、终端 Beta 帖子
ASImposium @doodlestein 面向 agent 与发起人的“工作坊 + 账本”系统,用于协作式科学研究 agent 研究埋没在本地滚动历史中,无法共享死胡同或评审状态 公开账本、绑定发起人的 agent、Claude Code / Codex / Grok Build 集成 RFC 网站, 仓库, 帖子
AI-lab docs skill pack @ArchiveExplorer 将官方实验室手册转成 agent 可直接使用的可安装技能 团队不用反复重读最佳实践,而是将其编码为可重复工作流 Markdown skills、实验室文档、可安装的 agent 工作流 Shipped 帖子

DeepSeek Harness 和 nac 是当天最清晰的构建模式:两者都把持久状态外置,并把主对话上下文视为应当受限、可检查,甚至可丢弃的对象,而不是不可侵犯的核心。DeepSeek 强调的是在单一插件运行时内实现最大可替换性;nac 强调的则是将编排器与执行过程分开,并只保留 worker 返回的紧凑 episodes。

GooeyPi 和 ASImposium 指向了第二种模式:构建者正在用更有主张的环境来包裹 agent 系统,而不再把它们留在原始聊天界面里。GooeyPi 把本地 agent 工作流封装成桌面式 GUI,而 ASImposium 则提出一种面向 agent 的研究协作公开记录。两者背后的驱动相同:一旦 agent 开始处理真实工作,团队需要的就不只是“完成任务”的界面,而是“协调工作”的界面。


6. 新动态与值得关注的内容

Harness-IF 量化了“指令遵循”里有多少其实只是巧合

@omarsar0 浮现出来(12 个赞、1 条回复、1,374 次浏览、21 次收藏)提到 Harness-IF,这是一篇关于如何在编码 agent 的不同提示界面上评估指令遵循能力的论文。对实践者而言,关键不在原始准确率,而在于:一旦评估剔除掉那些模型本来就会做的指令,并改用执行证据,性能就会下降;而系统提示词、项目文件和用户指令的重要性,都高于工具或技能描述。这与所有编写 AGENTS.md 文件、工具提示词或技能包的团队都直接相关。

Agent 工程的五层词汇体系有了一张清晰的公开示意图

@dmokafa 发布了(2 个赞、236 次浏览、3 次收藏)展示了一套紧凑的分类法,把提示词工程、上下文工程、harness 工程、循环工程和图工程分成不同层级。这条帖子的互动量不高,但配图格外有用,因为它为每一层都给出了明确的工作单位:一个提示词、一个窗口、一次运行、一个目标,以及一整条工作流。

图示比较了 prompt、context、harness、loop 和 graph engineering,作为 agent 系统中的不同层

监督与授权之间的区别,成为更尖锐的安全议题

@Snowizzie 认为(1 个赞、216 次浏览、1 次收藏)指出,即便 LangGraph 流程结构设计得很好,只要同一个软件系统仍持有签名密钥,它就不构成真正的安全边界。这一区别在数量上并未主导时间线,但它让当天更广泛的转向变得更清晰:外部授权、硬件隔离,以及以证据为门槛的审批。


7. 机会在哪里

[+++] 显式管理状态、日志和授权边界的长周期控制平面 —— DeepSeek Harness、nac、Championswimmer 关于企业级失败的讨论串,以及“监督 vs 授权”的图示,都指向同一个缺口:团队需要的是这样一类运行时——它能把临时 worker 上下文与持久任务状态分离,让模型可见事件保持可检查,并让敏感操作真正终止在审批边界上,而不是停留在软件层面的“表演式控制”。

[++] 可迁移的技能封装与市场分发 —— Figma skills、ArchiveExplorer 的实验室文档技能包,以及 Dannolan 的 MCP 市场演示,都表明市场对可复用 agent 行为存在明确需求:一次编写、通过社交发现、跨工具复用。机会不仅在发布和同步,也在自动调用、兼容性,以及评估某项技能到底改变了什么。

[+] 原生浏览器的项目设置与认证自动化 —— Doodlestein 对 Google Cloud 设置的抱怨,以及关于计算机操作仍需点击“是”的回复,都说明大量摩擦如今发生在终端之外。这里仍有空间:构建能安全穿越管理控制台、认证流程和其他重复设置界面的 agent,而不是让每个新项目都重新变成一份手动检查清单。


8. 要点

  1. Harness 现在是在作为产品竞争,而不再只是想法。 DeepSeek 和 Arcee 在同一天都发布了面向长周期 agent 工作的开源运行时,但对状态、控制和上下文漂移这一共同问题给出了不同答案。(DeepSeek, nac)
  2. 技能正成为 agent 能力的持久化单位。 Figma 将技能带入社区发布,ArchiveExplorer 把实验室手册打包成可安装工作流,而 MCP 市场的使用表明,agent 已开始通过工具界面“逛市场”,而不是等待定制集成。(Figma, ArchiveExplorer, dannolan)
  3. 最难的阻碍往往不是模型质量,而是其周边系统缺失。 Championswimmer 关于企业扩散的讨论、Doodlestein 对控制台设置的抱怨,以及 Harness-IF 的结果,都指向同一个问题:团队仍需要围绕模型建立更好的流水线、评估和设置工具。(championswimmer, doodlestein, omarsar0)
  4. 判断力很有价值,但没有成本和授权控制仍然不够。 Grok 4.6 因其编排判断力受到称赞,但配额耗尽限制了采用;与此同时,那些信号较弱的安全讨论则坚持认为,只有当授权真正脱离软件路径时,审批才算数。(kunchenguid, Snowizzie)