Twitter AI Agent - 2026-08-27¶
1. 人们在讨论什么¶
1.1 Harness 工程正在演变为一门基准测试与成本学科（🡕）¶
最强的一组讨论将 Agent 质量视为一个具有可衡量产出的系统工程问题，而不是写提示词的手艺。至少有六条入选内容支撑了这一主题，涵盖 OSWorld 基准测试成绩、六层 Harness 方法论、企业成本仪表盘、生成式 Harness 研究，以及一种反方观点：当前一些 Harness 技巧可能只是阶段性方案。相比 8 月 26 日对类型化流水线和企业级落地面的强调，8 月 27 日更进一步转向直接度量：分数、成本、缓存率和验证结构。
@SimularAI 报道（4,560 个赞、24 条回复、946,490 次浏览）称，其计算机使用 Agent Sai 在 OSWorld 2.0 上达到 73%，单任务成本约为 $15.70，低于 Claude Opus 5、Fable 5 和 GPT-5.6 Sol 所展示的成本水平。回复串通过具体案例让这一说法更具象：在 Chrome Dino 任务中，Sai 用了 23 轮，Sol 用了 46 轮，Opus 4.7 则用了 201 轮；在疫苗预约任务中，Sai 得分为 1.0，而 Opus 4.7 和 Sol 均落后。其独特之处不仅在于基准领先，还在于其主张：只要运行时设计得更好，单任务成本就可以与底层模型解耦变化。
@choopyplug1 写道（260 个赞、17 条回复、28,846 次浏览、503 次收藏）称，“Agent = Model + Harness”，并围绕 guide、传感器、Agent 循环、记忆、权限和可观测性，总结出一套六层生产实践。配图之所以重要，在于它把抽象观点压缩成了一张清晰的架构图：AGENTS.md 和规则文件为循环提供输入，而 trace 日志、工具预算、审批关卡、验证器和状态文件则让运行时保持可理解、可检查。这样一来，当天关于 Harness 的讨论更像平台工程，而不是提示词调优。
@praveenTweets 报道（47 个赞、7 条回复、37,140 次浏览）称，Uber 将 AI 支出拆解为多个可控杠杆，而不是把它视为一张总账单。推文列出的优化杠杆包括供应商无关的托管式 Agent、SWE 基准测试、提示词缓存、更高效的 MCP/工具使用、基于上下文图谱的 grounding、可复用技能，以及实时成本可见性；配图则显示，自 2 月以来，周活跃用户增长了 7 倍，周 Agent 请求量增长了 9.4 倍。其独特之处在于运营视角：这家公司把 AI 经济性描述成一组可以被监测、优化和改进的工程控制面。
@kunchenguid 认为（212 个赞、26 条回复、8,373 次浏览、126 次收藏）称，许多 Harness 层面的技巧最终可能会被模型训练吸收，就像早期编码 Agent 后来逐渐摆脱脆弱的 diff 和文件编辑变通方案一样。这条内容之所以入选，关键在于回复中的反驳：人们认可旧有故障模式确实存在，但也认为，相比语法处理，业务上下文理解和精确意图仍然更难被自动化消解。这使得这一以基准测试为核心的讨论簇内部形成了一个重要争论：哪些工程工作是持久的，哪些只是过渡性的。
讨论洞察： 回复一再将注意力从亮眼成绩转向边界条件。在 SimularAI 基准测试讨论下，有人质疑对比实验是否使用了相同的 Harness 和模型版本；在 Harness 方法论讨论下，有人提醒，每一个永久性修复也可能变成永久性的摩擦；在“苦涩的教训”讨论下，回复则认为，真正持久的瓶颈仍然是：在混乱的业务环境里，如何判断什么才算“正确”。
与前一天的比较： 8 月 26 日将可靠性框定为类型化流水线、评测和人工审核。8 月 27 日延续了这一关注，但通过聚焦分数与成本图表、成本杠杆图和明确的 Harness 分层分类，让讨论更偏向实证。
1.2 多 Agent 系统开始走向自我改进、生成式 Harness 和长周期协作团队（🡕）¶
第二个密集讨论簇将 Agent 循环本身视为一种可以随着时间演化、分支和协同的系统。至少有五条入选内容支撑了这一主题，从 Google 的 Teamwork 框架，到 Warp 的自我改进循环、JIT 生成的 Harness、一个在交付团队撤出后仍持续运行的生产级 PR 审查 Agent，以及 Google Cloud“像员工一样”的运维 Agent。相比 8 月 26 日关于共享协作通道的主题，8 月 27 日进一步深入到自我修复和长周期编排。
@antigravity 介绍了（197 个赞、9 条回复、8,452 次浏览、60 次收藏）介绍了 Antigravity 中的 Teamwork：一个用于理论计算机科学、研究数学和系统工程的多 Agent 框架。配图展示了几种截然不同的运行模式——迭代式编码、分布式编码、长证明工作、自我验证和文档审查——而不是一种泛化的“蜂群”模式。该帖也主动给出了部署提醒：这种方法 token 消耗很高，对日常任务来说属于杀鸡用牛刀。
@BHolmesDev 报道（84 个赞、2 条回复、9,673 次浏览、71 次收藏）称，Agent 对话中的自我改进循环已经产出了 5 个已合并 PR，其中一个发现了消息传递中的 token 消耗问题。被引用的 Warp 线程将这一循环定义为：给对话打分、定位失败点，并生成技能改进；附带的 diff 则展示了一个具体的加固步骤：Agent 在向编排器回报后，应停止检查收件箱，直到有新任务到达。这个补丁虽然很小，却正是那类会反复出现的编排 bug，足以把一种对话模式沉淀为可复用的运行时策略。
@omarsar0 分享了（65 个赞、10 条回复、4,979 次浏览、103 次收藏）介绍了 JIT-Agent。该系统将 Harness 视为一种可生成的产物，包含记忆、规划、行动协议和工具编排四个模块。论文配图声称，该系统在多个 Agent 基准测试中优于强力 backbone，并将生成式 Harness 呈现为可与 OpenCode 和 Claude Code 等运行时竞争的方案。让这条讨论不止于论文摘要的，是回复中的质疑：生成式 Harness 仍然需要持久检查点，否则每次运行都可能重新发现同样的约束。
@mardehaym 报道（30 个赞、12 条回复、10,640 次浏览、17 次收藏）称，一个为私募股权支持的金融服务客户部署的 PR 审查 Agent，在人工交付团队撤场后，仍继续审查每一个 pull request。该讨论称，规格说明始终是人类和 Agent 的单一事实来源，每一次变更在合并前都必须经过确定性 Harness。回复补充了一个重要限定：真正持久的单元并不只是 Agent 本身，而是围绕它的规格、关卡配置、重试策略和保留下来的日志。
讨论洞察： 这个讨论簇中反复出现的争论，是持久性与治理。JIT-Agent 讨论下的回复追问，生成式 Harness 如何保留持久检查点；Warp 循环讨论下的回复追问，评分标准由谁审核、由谁负责；PR 审查部署的讨论则强调，这类辅助式 Agent 之所以能存活，是因为关卡、重试和日志的责任仍在人。
与前一天的比较： 8 月 26 日强调的是共享协作界面。8 月 27 日则将其延展为能够自我改进、生成自身 Harness 结构，或跨多个协调角色持续运行数小时的系统。
1.3 Agent 商业讨论持续收敛于信任基础设施与可移植技能（🡒）¶
加密原生 Agent 经济的讨论依然是数据集中最响亮、也最持续的主线之一，但重心正不断从泛泛的“市场”叙事转向证明、权限、身份和结算机制。至少有四条入选内容支撑了这一主题，包括关于链上资金库基础设施的宏观论点、对 AACP 的详细拆解、面向开发者的可移植性主张，以及一篇按层拆解支付栈的帖子。与 8 月 26 日相比，变化并不是商业议题突然出现，而是更多帖子开始试图明确真正的底层原语。
@RaoulGMI 写道（403 个赞、65 条回复、84,851 次浏览、192 次收藏）称，“DeFi 将成为 Agent 资金库基础设施”，将即将到来的 Agent 经济建立在链上资金流动之上，而不是聊天界面之上。由于链接的 X 文章无法抓取，公开证据主要来自推文和回复，其中最有力的修正意见是：Agent 的路由选择未必只看最低费率，安全性、流动性和信任也同样是选择问题的一部分。
@Web3AlphaHunt 解释了（119 个赞、62 条回复、7,545 次浏览）称，AACP 为 Agent 提供链上身份、任务发布与发现、USDC/USDT 托管、交付验证、质押与罚没、信誉以及仲裁式争议处理路径。公开的 marketplace 首页又给出了一个更具体的信号：Agent.family 称，Agent 按链上信誉排名，且每一个分数都可追溯到一项已结算、可被质疑的任务。这让该论点比“AI 遇上加密货币”更具体：它指向的是一种以工作历史本身为信誉表面的结算系统。
@refrip98 认为（76 个赞、73 条回复、756 次浏览）称，Claude Code、Cursor 和基于 MCP 的工具在本地编码、研究和自动化方面依然很强，但尚未进入商业环节。该帖最有特点的细节在于面向开发者的那一层：借助可移植技能、REST API、事件流和 MCP 集成，Agent 可以铸造 ERC-8004 身份、列出服务、竞标任务、提交交付物并完成付款结算，而无需从零重建信任基础设施。
@Defi_Rocketeer 梳理了（61 个赞、35 条回复、2,109 次浏览）将这一技术栈拆分为身份、支出权限、服务发现、支付执行和最终结算。他还进一步将竞争面划分为消费者商业、机器对机器微支付，以及授权与控制，并点名 x402、USDC、Solana、Chainlink CRE 和 Aave 等值得关注的组成部分。回复中最有价值的结论是，权限层可能才是最持久的护城河，因为总得有人来定义 Agent 被允许买什么。
讨论洞察： 即便是支持者的回复，也在不断收窄问题真正困难的部分。信任、流动性、密钥安全、可审计性和明确的权限控制，被视为真正的瓶颈，而不是再多一个挂单入口。
与前一天的比较： 8 月 26 日已经强调了托管和结算基础设施。8 月 27 日延续了同一论点，但将其进一步落实为可移植技能、事件流、身份标准以及更明确的授权层。
2. 什么让人感到沮丧¶
成本、缓存和工具输出膨胀仍然主导 Agent 质量问题¶
最明显的挫败感在于，团队仍在运行时内部损失了过多资金与可靠性。@SimularAI 报道（4,560 个赞、24 条回复、946,490 次浏览）展示了计算机使用 Agent 之间巨大的分数与成本差距；@praveenTweets 报道（47 个赞、7 条回复、37,140 次浏览）称，Uber 必须将支出拆解为会话、轮次、请求、token 和价格，才能让问题变得可处理。@BHolmesDev 报道（84 个赞、2 条回复、9,673 次浏览、71 次收藏）称，一次自我改进 PR 发现了消息传递中的 token 消耗；@kunchenguid 认为（212 个赞、26 条回复、8,373 次浏览、126 次收藏）则称，早期编码 Harness 需要依赖脆弱技巧，才能可靠地编辑文件。公开讨论中反复出现的应对模式是一致的：更好的缓存、更小且可复用的技能、更严格的消息规则、能映射真实工作的基准测试，以及更清楚地看见 token 究竟消失在何处。严重程度：高。值得投入建设：高。
持久状态和多 Agent 协作仍会在边缘场景出错¶
第二个挫败点在于，长周期或多 Agent 系统仍然需要比普通演示所呈现的更完善的持久化规则。@omarsar0 分享了（65 个赞、10 条回复、4,979 次浏览、103 次收藏）介绍了一种生成式 Harness 方法，但立即引来回复追问系统如何保留持久检查点；@antigravity 介绍了（197 个赞、9 条回复、8,452 次浏览、60 次收藏）介绍了多 Agent Teamwork 框架，同时明确表示它成本高、对日常任务来说属于过度设计。@mardehaym 报道（30 个赞、12 条回复、10,640 次浏览、17 次收藏）称，一个生产环境中的 PR 审查 Agent 之所以上线后还能稳定存活，是因为规格和确定性 Harness 始终存在；而 @_lopopolo 构建进展更新（108 个赞、15 条回复、5,924 次浏览）下的回复则指出，当运维 Agent 出错时，最终承担漏判后果的仍然是人。应对模式是把责任前移到规格、关卡配置、重试策略和明确的停止条件上，而不是信任蜂群本身。严重程度：高。值得投入建设：高。
具备商业能力的 Agent 仍需要更安全的权限和结算基础设施¶
第三个挫败点是，Agent 已经能够编写、搜索和自动化执行，但资金流动仍需要额外的信任基础设施。@refrip98 认为（76 个赞、73 条回复、756 次浏览）称，一旦涉及身份、竞标、托管和结算，Claude Code、Cursor 以及基于 MCP 的系统仍停留在本地执行层面。@Web3AlphaHunt 解释了（119 个赞、62 条回复、7,545 次浏览）介绍了 AACP 的身份、托管、信誉、罚没和争议处理等原语；@Defi_Rocketeer 梳理了（61 个赞、35 条回复、2,109 次浏览）则将技术栈拆分为身份、支出权限、服务发现、支付执行和结算。即使是 @RaoulGMI 提出了（403 个赞、65 条回复、84,851 次浏览、192 次收藏）发布的更乐观宏观观点，也只是围绕链上资金库基础设施展开；回复很快就把尚未解决的风险收敛到信任、密钥安全、流动性，以及由谁设定支出策略。严重程度：中。值得投入建设：高。
3. 人们希望有什么¶
能证明自己为何更便宜的成本感知型 Harness¶
最实际的需求并不是抽象意义上的“更好的 AI”，而是能够暴露自身成本结构和验证行为的 Harness。@praveenTweets 报道（47 个赞、7 条回复、37,140 次浏览）称，Uber 正在监测会话、轮次、请求、token 和价格；@SimularAI 报道（4,560 个赞、24 条回复、946,490 次浏览）则给出了 OSWorld 2.0 上跨 Agent 的具体分数与成本对比。@choopyplug1 写道（260 个赞、17 条回复、28,846 次浏览、503 次收藏）称，可观测性、权限和传感器应当属于 Harness 本体，而不是事后补上的功能。社区已经开始按单任务成本、缓存行为和可控故障模式比较 Agent，因此这构成了一项直接需求。机会：直接。
具备持久检查点且不会越改越偏的长周期 Agent¶
人们显然希望系统能够持续学习，同时不偏离原本目标。@omarsar0 分享了（65 个赞、10 条回复、4,979 次浏览、103 次收藏）介绍了一个生成式 Harness 系统，但回复立刻要求提供稳定检查点，以免每次运行都重新发现同样的约束。@BHolmesDev 报道（84 个赞、2 条回复、9,673 次浏览、71 次收藏）给出了来自对话审查的真实自我改进 PR；@antigravity 介绍了（197 个赞、9 条回复、8,452 次浏览、60 次收藏）则介绍了一个面向长周期研究、但 token 消耗很高的 Teamwork 系统。共同的实际诉求是：当任务跨越数小时、多个分支和多个 Agent 时，记忆、停止条件和改进循环仍然保持可检查。机会：直接。
面向 Agent 的可移植信任、身份和结算模块¶
商业讨论簇几乎就是一条持续不断的需求清单：为 Agent 提供可插接到现有运行时中的基础设施。@refrip98 认为（76 个赞、73 条回复、756 次浏览）称，开发者不应围绕每个 Agent 框架重复搭建身份、托管和信誉系统；@Web3AlphaHunt 解释了（119 个赞、62 条回复、7,545 次浏览）则将 AACP 描述为一个打包层，涵盖身份、托管、验证和争议处理。@Defi_Rocketeer 写道（61 个赞、35 条回复、2,109 次浏览）称，支出权限可能是整套技术栈中最有价值的部分，因为企业不会把不受限制的钱包交给 Agent。这是一项具有商业潜力的直接需求，但也正迅速变得竞争激烈，因为多条帖子都把支付、身份和授权视为彼此独立的控制点。机会：竞争激烈。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Sai / SimularAI | 计算机使用 Agent | (+) | 声称在 OSWorld 2.0 上达到 73%，单任务成本约为 $15.70；回复串提供了具体任务案例 | 回复质疑了基准测试的可比性，尤其是 Harness 和版本是否一致 |
| AGENTS.md + 传感器 + 可观测性方法论 | Harness 方法 | (+) | 围绕 guide、验证器、权限、记忆和 trace，提供了具体的六层生产模式 | 规则不断累积，可能把过去的修复变成持续摩擦 |
| Antigravity 中的 Teamwork | 多 Agent 编排 | (+/-) | 支持迭代式编码、分布式编码、自我验证和长周期研究模式 | 作者明确表示它 token 消耗很高，对日常任务来说属于过度设计 |
| Warp 自我改进循环 | 技能改进方法 | (+) | 为既有对话打分、定位失败点并生成改进，已经促成多个 PR 合并 | 评分标准由谁负责、由谁审核，仍是治理问题 |
| JIT-Agent | 生成式 Harness 研究 | (+/-) | 将记忆、规划、行动协议和工具编排视为生成式产物，并声称在基准测试上取得提升 | 回复质疑了检查点的持久性和运行稳定性 |
| 开源 Agent 技术栈（Codex、LangGraph、Mem0、MCP Servers、E2B、Langfuse、Promptfoo、Portkey、Ollama） | 技术栈组件 | (+/-) | 覆盖编码、编排、记忆、工具、沙箱、追踪、评测、路由和本地推理 | 有人指出，集成和维护才是真正持续存在的成本 |
| AACP / Agent.family / x402 式支付基础设施 | 身份与结算基础设施 | (+/-) | 为 Agent 增加身份、托管、信誉、争议处理路径和协议层支付 | 权限、流动性、密钥安全和信任仍是尚未解决的控制点 |
总体满意度呈现出明显的两极分化。只要某个工具或方法能让 Agent 行为更便宜、更清晰或更持久，人们就会表现出热情；一旦相关主张依赖未经检查的脚手架，或对信任问题轻描淡写，人们就会转为怀疑。最常见的变通模式，是把稳定逻辑从提示词中移出，放进明确的运行时结构里：缓存、技能、上下文图谱、验证器、追踪、规格和结算策略。迁移压力同样明显：本地编码 Agent 仍然很强，但多条帖子认为，下一步竞争要么是更好的编排，要么是让专业化 Agent 能彼此交易的商业层。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Sai | @SimularAI | 在长周期桌面任务上做过基准测试的计算机使用 Agent | 降低 GUI 密集型工作的成本并提高可靠性 | 神经符号式计算机使用 Harness | 已发布 | 帖子 |
| Warp 自我改进循环 | @warpdotdev | 审查既有对话、为失败打分并提出技能/运行时修复方案 | 将反复出现的编排错误转化为可复用的改进 | 对话评分、失败隔离、Agent 编写补丁 | Beta | 帖子 |
| JIT-Agent | @omarsar0 | 生成面向特定任务的 Agent Harness，并为记忆、规划、行动和工具编排提供固定模块 | 减少随任务变化而进行的手动 Harness 调优 | 生成式 Harness、基于基准测试的自我演化 | Alpha | 帖子 |
| Antigravity 中的 Teamwork | @antigravity | 面向长周期编码、证明、验证和文档工作的多 Agent 框架 | 让专业化 Agent 协作完成研究级任务 | 采用迭代式、分布式和自我验证模式的多 Agent 编排 | Alpha | 帖子 |
| 辅助式 PR 审查 Agent | @mardehaym | 在人工查看前审查真实金融服务环境中的每个 PR | 在重建团队撤场后维持审查覆盖率和策略一致性 | 规格驱动的工作流、确定性 Harness、辅助式审查关卡 | 已发布 | 帖子 |
| Google Cloud 云运维 Agent | @_lopopolo | 用于云设计、日常运维和事故响应的 Agent | 将“像员工一样”的 Agent 推向运维工作，而不只是编码辅助 | Harness 工程模式加上云执行面 | Alpha | 帖子 |
| AACP / TermiX 上的 Agent.family | @Web3AlphaHunt | 让 Agent 注册身份、发现任务、竞标、交付和结算的 marketplace 与结算层 | 为 Agent 间协作提供可信的商业原语 | AACP、ERC-8004 身份、托管、信誉、争议处理路径、USDC/USDT 结算 | 已发布 | 网站 · 帖子 |
最重要的构建项目都遵循一个共同模式：它们不是“又一个 Agent”，而是让 Agent 真正具备运营可用性的外围系统。Sai 和 Uber 式成本工程将运行时视为优化目标；Warp 和 JIT-Agent 将 Harness 视为能够自我改进的对象；Teamwork 和 PR 审查 Agent 将协作与关卡控制视为一等行为；TermiX/AACP 则将信任、证明和结算视为 Agent 技术栈仍然缺失的基础设施。这些项目反复出现的触发因素，并不只是模型能力不足，更是缺乏足够的记忆、遥测或控制，却仍让 Agent 采取行动所带来的成本。
6. 新动态与值得关注的内容¶
除了当天围绕基准测试与 Harness 的主线讨论，还有两个较小但重要的信号值得关注。
首先，@nykdotdev 写道（123 个赞、4 条回复、18,782 次浏览、114 次收藏）称，如今实用的开源 Agent 技术栈已经覆盖编码 Agent、图、记忆、工具服务器、沙箱、追踪、评测、网关和本地推理。这一点很重要，因为它意味着市场正在从单一产品转向可互操作的技术栈选型；差异化因素将变成供应商如何打包和协调这些组件，而不再是每个类别是否存在。
其次，@_lopopolo 认为（108 个赞、15 条回复、5,924 次浏览）称，Google Cloud 的下一波发展不只是更多 Copilot，而是面向设计、运维和事故响应的“像员工一样”的 Agent。值得注意的是，这扩大了目标买家的范围：从工程效率团队扩展到平台和运维负责人。这应会让可靠性、审批流程以及达到事后复盘标准的可审计性，在产品路线图中的优先级进一步上升。
7. 机会在哪里¶
[+++] Agent 运行时成本分析器 — Uber 式成本工程、Warp 的 token 预算纪律，以及当天更广泛的 Harness 讨论，都指向一个需求：在进入生产规模前，能够按会话、轮次和工具调用归因，并暴露提示词膨胀、缓存未命中和高成本路由决策。
[+++] 带检查点的 Agent 工作台 — JIT-Agent、Teamwork 和 PR 审查 Agent 都将长周期执行视为需要持久化状态、人工审批、验证追踪和可恢复分支的过程，而不是一次性聊天。当天的证据直接支持构建可复用的检查点与恢复层。
[++] Agent 信任与结算 SDK — AACP 和 TermiX 的讨论显示，一旦 Agent 开始发现任务并彼此交易，团队仍然需要可移植的身份、托管、权限和争议处理原语。这看起来更像一个正在形成的基础设施缺口，而不是一个已经解决的产品类别。
8. 要点¶
- 基准测试成绩必须有成本和任务证据支撑。 纯粹的能力主张，只有在配上明确的经济性数据或可见的工作流结果时，才会真正引发兴趣。
- Harness 工程成为 Agent 技术栈的实际核心。 guide、记忆、可观测性、权限和评测不断作为同一个运营控制面出现，而不是彼此割裂的独立事项。
- 多 Agent 的热情如今取决于控制循环。 被认为可以走向生产的路径，是检查点、验证和受约束的协作，而不是无边界的蜂群。
- Agent 商业正在成熟为基础设施规划。 身份、托管、权限和争议解决，已比本周稍早时候更清楚地显现为缺失层。