Twitter AI Agent - 2026-08-28¶
1. 人们在讨论什么¶
1.1 AI 工程重新回到软件基本功与专业化路径（🡕）¶
8 月 28 日最明显的变化是，ai-agent 这波讨论不再过多停留在泛泛的自主性宣称上，而是更多聚焦于构建者究竟应该学习什么、落实什么。至少有 4 条帖子支撑了这一话题群：Andrew Ng 的软件工程技能图谱、Asmah 发布的两篇高信号构建者课程/专业化帖子，以及 Tidewave 发布的 repo-native 设计界面。相比 8 月 27 日对 harness 基准测试和 agent commerce 基础设施的关注，8 月 28 日把讨论扩展到了让智能体系统真正可交付的周边工程学科。
@AndrewYNg 分享（734 个赞、48 条回复、38,872 次浏览、1,103 个收藏）发布了一份面向智能体时代、围绕软件工程基本功展开的 AI 工程技能图谱。真正更有启发的是回复区：多位工程师认为，数据建模以及前后端边界划分如今反而更重要了，因为高效智能体可以低成本生成代码，却仍会做出代价高昂且难以逆转的架构决策。其独特视角在于，“基本功”被重新定义为对不可逆权衡的判断力，而不是语法熟练度。
@asmah2107 发布（150 个赞、7 条回复、6,728 次浏览、273 个收藏）发布了一套庞大的自建课程体系，涵盖 reasoner、agent loop、推理服务器、向量数据库、eval harness、guardrail、提示缓存、结构化输出和网关；随后，后续补充（101 个赞、10 条回复、4,247 次浏览、139 个收藏）又列出 5 个值得深挖的应用方向：智能体架构、评测/可观测性、混合 RAG/上下文工程、推理优化和数据管道。关键不在于清单有多长，而在于回复中的社区纠偏：先从 eval harness 做起，而且不要相信只由系统作者自己编写的测试。
@josevalim 介绍（51 个赞、4 条回复、3,400 次浏览、19 个收藏）介绍了 Tidewave 的全新设计画布：它是一个独立 HTML 文件，在应用内部运行，复用真实主题，并刻意采用原生 JS/HTML/Web Components，而不是再叠额外框架层。这让当天关于课程体系的讨论落到了实处：构建者不只是口头上说“要学基本功”，而是在交付对智能体友好的产品界面，让设计、代码和版本控制处于同一个 repo-native 闭环里。
讨论洞察： 这些帖子下最有力的回复最终都指向同一点：智能体降低写代码成本的速度，快于其降低撤销错误系统决策成本的速度。因此，技能价值正从机械式实现转向评测、架构和判断力。
与前一天对比： 8 月 27 日强调通过 harness 工程让智能体变得可控。8 月 28 日延续了这一关注点，但把它放进了更广泛的 AI 工程技术栈中：基本功、专业化、评测，以及 repo-native 构建界面。
1.2 团队通过 harness 经济性、部署界面和可量化 ROI 评估智能体（🡕）¶
第二个高密度讨论群聚焦于：智能体产品是一类运营系统，其价值必须以使用情况、质量和控制能力来衡量，而不只是模型品牌。至少有 4 条帖子支撑这一趋势：一篇详细的 Devin 评测、“云软件工厂”论点、Vercel 的 repo-owned eve 发布，以及 OpenRouter 面向长周期工程任务推出的 GLM-5.3。相比 8 月 27 日对基准成本的讨论，8 月 28 日更进一步追问买方真正关心的问题：究竟是什么让一个智能体环境比另一个更值得部署？
@Da7_Tech 发布（124 个赞、46 条回复、9,507 次浏览、66 个收藏）是在大量使用 Devin 后发布的、当天最详尽的用户侧 harness 评测之一。帖子称，在一项 500,000 词的任务中，17 个并行的 Sol Max 智能体只消耗了 4% 的额度；Sol 在 Devin 中的价格约为每百万 token 6 美元；处理的近 10 亿 token 中约 95% 来自缓存。帖子还补充了基准测试通常不会呈现的产品细节：云端机器模式价值很高，但用户仍希望获得更好的用量可见性，减少因引导消息导致的子智能体取消，并提供真正的 goal mode。
@zachlloydtweets 认为（42 个赞、6 条回复、3,012 次浏览、46 个收藏）认为，编码智能体应被部署为“云软件工厂”：闭环、云托管、以代码定义、可由智能体编辑、默认支持多模型，并具备评测与自我改进能力的 SDLC 系统。随附的仪表盘让这一论点更具体：667 个 PR 的单次成本降至 57.55 美元，同时质量和效率面板均呈积极趋势。@rauchg 同样强调（104 个赞、12 条回复、13,851 次浏览、55 个收藏）则认为，Vercel 的 eve 售卖的是对完整智能栈的所有权——运行时、模型选择、技能、工具、连接能力、沙箱和部署——并由用户自己拥有的 Git 仓库提供支撑。
@OpenRouter 补充（138 个赞、8 条回复、11,164 次浏览）释放出模型层信号：推出面向复杂软件工程、长周期智能体和网络安全的开放权重 GLM-5.3，支持 1M 上下文和可配置的推理强度。综合来看，这些帖子表明，市场正在从模型经济性、仓库所有权、云运行时设计和持续度量等多个维度评估智能体技术栈。
讨论洞察： 回复不断把话题拉回到智能体上线后买方真正关心的指标：评审时间、回滚率、识别并弃用糟糕 harness 所需的时间，以及人在不破坏并行工作的情况下是否仍能进行引导。
与前一天对比： 8 月 27 日聚焦于基准分数/成本纪律。8 月 28 日则把讨论扩展到产品选择和运营模式问题：仓库所有权、缓存经济性、云托管工厂，以及覆盖整个技术栈的 ROI 度量。
1.3 可靠性工作聚焦于控制器、遥测和过程级评测（🡕）¶
第三个主要主题是：可靠性越来越通过轨迹、控制器和过程诊断来衡量，而不再只看最终分数。至少有 5 条帖子支撑这一话题群：Dot 开源的 Reflex 工程层、美团/LongCat 的自主研究基准、Greg Mushen 的生产级智能体架构、Praxist 关于并行研究的论点，以及 Ashpreet Bedi 对工作流的批评。相比 8 月 27 日围绕生成式 harness 和协作的讨论，8 月 28 日更强调是什么让智能体系统能够恢复、持续运行并解释自身行为。
@usedotai 开源了（56 个赞、4 条回复、1,614 次浏览）介绍了 Dot Reflex 14B 背后的工程层，包括推理运行时、本地 API、轨迹 schema、测试、基准测试凭证和训练来源。关联仓库对其基准测试能证明什么、不能证明什么，说明得格外谨慎，明确警告其公布的 100% 分数是合成结果，而非生产验证。@Meituan_LongCat 补充（61 个赞、2 条回复、2,390 次浏览、15 个收藏）介绍了一项包含 36 个任务的 AI 研发基准：252 个方案中只有 3 个被认定为具有新颖性，而可靠性缺口和 harness 影响比峰值性能更重要。
@gregmushen 分享（36 个赞、2 条回复、1,488 次浏览、49 个收藏）介绍了一种生产级智能体架构：由 Hermes 判断层将任务路由到精简、确定性的 CLI，并通过 Alloy/Grafana 遥测和 observer hook 将失败反馈回系统。@ashpreetbedi 认为（18 个赞、8 条回复、1,512 次浏览、19 个收藏）认为，MCP 时代的工作流在不同产品之间仍缺少持久化的工作流身份、持久状态、重试机制、权限和幂等性。换言之，可靠性越来越是工作流和控制器问题，而不是一次性推理问题。
讨论洞察： 更尖锐的回复并不反对雄心勃勃的智能体系统，而是反对那些无法重放运行过程、无法追溯变更，或在另一个产品的第六步失败后无法安全恢复的系统。
与前一天对比： 8 月 27 日强调能够自我生成或改进的 harness。8 月 28 日则追问，什么才能让这些系统保持诚实：轨迹产物、遥测、明确的控制决策，以及可重复的工作流状态。
1.4 信任基础设施仍然活跃，但具体讨论转向证明定价与授权（🡒）¶
智能体商业化这条线依然强劲，但并未明显超出前一天的范围。最具体的新增内容来自一批把信任本身视为可定价产品的帖子：通过商业层实现专业化、将证明阶梯与资本效率挂钩，以及将真人证明主张限定在足以支持委托和溯源的狭窄范围内。相比 8 月 27 日更宽泛的“身份/托管/信誉”框架，8 月 28 日把证明这一侧讲得更明确了。
@RMac_5 认为（117 个赞、92 条回复、463 次浏览）认为，专业化智能体一旦能够通过共享商业层发布任务、竞价、执行并结算工作，就会变得更加有用。@AnhDaDen811 将其定义为（125 个赞、71 条回复、7,791 次浏览）将 TermiX 定义为“信任定价引擎”，其证明阶梯涵盖人工小组、TEE、zkVM 和组合证明，并涉及质押/锁定与信誉之间的权衡。@SingularityNET 扩展（201 个赞、7 条回复、2,791 次浏览）则把同一理念延伸至真人证明基础设施，主张组合使用范围明确的主张——存在性、唯一性、连续性和授权——而不是输出一个笼统的“真人”判定。
讨论洞察： 最强烈的质疑已不再是“智能体为什么需要支付能力”，而是“这项任务需要什么级别的证明，以及如何区分身份、授权和正确性？”
与前一天对比： 8 月 27 日的商业化帖子强调身份、托管和结算基础设施。8 月 28 日延续了这些主题，但将讨论进一步聚焦于定价化证明、专业化劳动以及更狭义的授权主张。
2. 人们感到沮丧的地方¶
跨产品工作流仍会在状态、身份和重试机制上出问题¶
当天最明确的未满足需求帖子，本质上是一份关于编排质量的挫败报告。@ashpreetbedi 认为（18 个赞、8 条回复、1,512 次浏览、19 个收藏）认为，MCP 正在改善工具串联，但团队仍被夹在两种方案之间：一种是随机编排工具的智能体，另一种是本质上由长提示词加 shell 脚本组成的“技能”。回复进一步明确了运营层面的痛点：当任务跨越多个产品时，最先失效的正是持久化工作流身份、版本化步骤、持久状态、重试机制、权限和幂等性。这与其说是理论上的抱怨，不如说是对企业采用为何仍处于早期阶段的直接解释。严重程度：高。值得构建：高。
买方仍难以区分模型质量、harness 经济性和用户体验¶
另一个强烈的痛点是，智能体技术栈仍难以公平评估，因为价格、缓存行为、界面设计和模型选择会一起变化。@Da7_Tech 报告（124 个赞、46 条回复、9,507 次浏览、66 个收藏）展示了异常强劲的 Devin 结果，但仍指出用量可见性不足、引导过程中子智能体会被中断，以及缺少 goal mode。@zachlloydtweets 回应（42 个赞、6 条回复、3,012 次浏览、46 个收藏）则主张，应根据真实工作流数据而不是“感觉”来评估闭环云工厂。即便是 @OpenRouter 将其定位为（138 个赞、8 条回复、11,164 次浏览）对 GLM-5.3 的介绍，也采用了软件工程、长周期智能体和网络安全等实际工作负载，以及推理模式和 1M 上下文等指标，因为如今仅凭模型标签已经不够。严重程度：高。值得构建：高。
可靠性仍胜过新颖性，当前智能体更擅长优化而非研究¶
研究类帖子也坦率揭示了当前仍会失败的地方。@Meituan_LongCat 报告（61 个赞、2 条回复、2,390 次浏览、15 个收藏）指出，在其自主研究基准中，252 个方案只有 3 个被认定为具有新颖性，而 harness 选择主要改变的是可靠性和经验复用，而不是创造力。@usedotai 分享（56 个赞、4 条回复、1,614 次浏览）介绍控制器与轨迹技术栈，正是因为只有最终分数、没有运行产物，会引发无休止的争论。@polydao 认为（25 个赞、12 条回复、647 次浏览、18 个收藏）认为，并行研究协作者在成本和产出上可以胜过单一研究循环，但这仍被描述为更好的搜索过程，而不是具备真正自主发现能力的证据。严重程度：中。值得构建：高。
一旦智能体开始代表人类进行交易或行动，信任与归因仍未解决¶
商业/基础设施这组讨论持续围绕同一个难题展开：一旦智能体开始动用资金、身份或受托权限，信任就不能继续停留在隐含状态。@AnhDaDen811 写道（125 个赞、71 条回复、7,791 次浏览）认为，TermiX 的意义在于为证明定价，让诚实成为成本更低的路径；而 @SingularityNET 认为（201 个赞、7 条回复、2,791 次浏览）认为，真人证明应当发布范围狭窄的主张，而不是一个通用的真人标签。回复才是真正的摩擦记录：即使身份或存在性证明有效，也无法解决正确性、授权或委托凭证问题。严重程度：高。值得构建：高。
3. 人们希望存在什么¶
面向 MCP 时代跨产品执行的版本化工作流层¶
最明确的直接需求，是在随机工具编排与高度依赖提示词的“技能”之间提供某种中间层。@ashpreetbedi 认为（18 个赞、8 条回复、1,512 次浏览、19 个收藏）认为，跨产品工作流应通过 MCP 以相对确定、可复用的形式暴露给智能体；回复串则补充了缺失的基础能力：版本化步骤、持久化工作流身份、类型化状态、重试机制、权限和幂等键。这看起来是直接的产品需求，而不只是一个想法。机会：直接。
随时间衡量质量、成本和改进效果的闭环智能体工厂¶
多篇帖子都暗示，缺失的产品不是又一个模型封装，而是一个可度量的智能体工作操作系统。@zachlloydtweets 描述（42 个赞、6 条回复、3,012 次浏览、46 个收藏）主张，工厂应以代码定义、API 优先、云托管、经过基准测试并能够自我改进；@Da7_Tech 展示（124 个赞、46 条回复、9,507 次浏览、66 个收藏）则指出，用户已经在根据缓存率、额度效率、云端执行和引导行为评判产品。实际需求是一个控制平面：能够比较不同 harness、解释支出，并安全地合并改进。机会：直接。
具备可重放轨迹、来源信息和人类可读遥测的开放控制器¶
当天最有力的构建者产物表明，市场需要能够在事后自我解释的控制器基础设施。@usedotai 开源了（56 个赞、4 条回复、1,614 次浏览）提供了运行时代码、轨迹 schema、基准测试凭证和训练来源；@gregmushen 展示（36 个赞、2 条回复、1,488 次浏览、49 个收藏）则展示了以遥测为先的生产架构。对于希望超越演示阶段的团队而言，这似乎是直接需求，但随着越来越多构建者将 trace 和 observer loop 视为核心产品价值，该领域的竞争也在加剧。机会：竞争性。
能为证明定价、且不绑定单一技术栈的信任与授权模块¶
商业层相关帖子暗示，市场需要可复用的信任原语——身份、授权、证明选择、托管和争议处理——并将其置于智能体框架旁边，而非内置其中。@RMac_5 认为（117 个赞、92 条回复、463 次浏览）认为，智能体能够通过共享结算层协作后，专业化的价值会进一步提升；@AnhDaDen811 认为（125 个赞、71 条回复、7,791 次浏览）则认为，证明级别本身应当成为可配置的经济选择。由于已有多个项目在围绕身份/证明/托管展开，这一方向商业吸引力较强，但竞争也日益激烈。机会：竞争性。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Devin | 编码智能体 harness | (+/-) | 根据一份详细的用户评测，具备出色的缓存效率、宽松的打包经济性、严谨的执行能力以及云机器隔离 | 用量可见性不足，引导可能中断子智能体，且仍缺少 goal mode 控制 |
| 云软件工厂 | 部署模式 | (+) | 将编码智能体视为可度量的 SDLC 闭环，跟踪成本/质量/效率并支持自我改进 | 需要大量云端/运行时投入，以及严格的数据采集 |
| eve by Vercel | repo-owned 智能体界面 | (+) | 为用户提供由 Git 支撑的运行时、模型选择、MCP 连接、部署能力和技术栈所有权 | 公开证据仍更多体现为产品界面的承诺，而非深入的运营数据 |
| GLM-5.3 | 开放权重模型 | (+) | 面向长周期软件工程和网络安全，并支持 1M 上下文和可配置的推理强度 | 仍需要配套 harness 和评测环境，才能在生产中发挥作用 |
| Dot Reflex 工程层 | 控制器/运行时技术栈 | (+) | 除权重外，还提供运行时、本地 API、轨迹、测试、基准测试凭证和来源信息 | 明确尚不能证明其具备生产能力；基准分数本身是合成结果 |
| Tidewave 设计画布 | 对智能体友好的产品界面 | (+) | 借助可分享的 HTML 和原生 Web Components，将设计实验保留在真实应用和仓库内 | 更适合希望采用 repo-native 工作流，而不是独立设计工具的团队 |
| 美团/LongCat 研究基准 | 评测方法 | (+/-) | 除最终分数外，还衡量问题设定、执行、反馈控制、经验复用和可靠性 | 结果显示当前智能体仍难以产生新颖成果，因此更好的评测本身无法解决能力缺口 |
| AACP / TermiX 证明阶梯 | 信任/结算方法 | (+/-) | 在智能体商业化中明确证明级别、质押、资本锁定和信誉 | 授权、正确性和主流采用仍存在未解问题 |
总体而言，可信度最高的方法都将稳定逻辑从隐藏提示词中移出，转化为明确结构：仪表盘、仓库定义、轨迹 schema、类型化工作流或证明阶梯。当工具让智能体更容易衡量或引导时，满意度最高；而当主张依赖不透明的基准测试或宽泛的商业化承诺时，质疑就会上升。迁移趋势正变得越来越清晰：智能体团队正在围绕运行时、可观测性、评测、所有权和信任组装技术栈，而不是押注于单一模型或框架层。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| eve | @vercel / @rauchg | 创建并部署由用户自己拥有的 Git 仓库支撑的智能体 | 让团队以 repo-native 的方式拥有运行时、模型、工具、MCP 连接和部署能力 | 托管式智能体运行时、模型选择器、MCP 连接、基于 Git 的部署 | 已发布 | 帖子 · 启动器 |
| Dot Reflex 工程层 | @usedotai | 开源 Dot Reflex 14B 背后的运行时/控制器层 | 提供可重放轨迹、基准测试凭证和来源信息，而不是不透明的分数 | 推理运行时、本地 API、轨迹 schema、测试、来源信息工具 | Beta | 帖子 · 仓库 |
| Tidewave 设计画布 | @josevalim | 集成在应用内、可与编码智能体协作的设计画布，以可分享 HTML 文件形式存在 | 将设计迭代保留在应用和仓库内，而不是使用独立工具链 | Web Components、原生 JS/HTML、Phoenix/Rails/Vite 软件包集成 | 已发布 | 帖子 |
| Praxist Beta | @Sapient_Int / 由 @polydao 分享 | 由并行协作者和 PI 式选择循环组成的自主研究团队 | 以低于赢家通吃式研究循环的成本探索更多假设 | 并行研究协作者、共享内存、评估器/PI 小组、领域专用工具 | Beta | 帖子 |
| Google Cloud 云运维智能体 | @_lopopolo | 用于云设计、日常运维和事故响应的智能体 | 将智能体的价值从编码辅助扩展到运营责任 | harness 工程模式加云端执行界面 | Alpha | 帖子 |
| OpenWater Proof of Humanity | @SingularityNET | 面向去中心化 AI 的多源真人证明和授权基础设施 | 将存在性、唯一性、连续性和授权拆分为可检查的主张 | 设备/认证者主张、隐私保护密码学、面向溯源的身份层 | Alpha | 帖子 |
| TermiX / AACP 信任层 | @termix_ai 生态倡导者 | 共享商业层，智能体可在其中注册身份、竞标工作、交付证明并结算任务 | 为智能体间商业化增加信任、专业化、托管和证明定价 | 身份、信誉、托管、证明阶梯、USDC/USDT 结算、争议处理 | 已发布 | 帖子 |
| LongCat 自主研究基准 | @Meituan_LongCat | 面向多种模型的持续 AI 研发任务基准与项目界面 | 除最终分数外，衡量可靠性、经验复用和新颖性 | 36 项任务、756 条轨迹、过程评测、自动化 harness 优化 | 研究 | 帖子 |
最成熟的项目，是那些在封装周边结构，而非原始智能本身。Eve 和 Tidewave 让仓库所有权及对智能体友好的构建界面成为产品功能。Dot Reflex 和 LongCat 将轨迹、过程评测和来源信息视为智能体主张周围的证据层。Praxist 以及 Google Cloud 的运维智能体方向，则将目标从编码助手扩展到更持久的研究和运营系统。与此同时，TermiX/AACP 和 OpenWater 试图解决智能体一旦需要市场信任或受托权限之后会发生什么。不同类别之间的共同模式是：基础设施优先。
6. 新动态与值得关注的项目¶
除当天的主要讨论群之外，还有 3 个较小的信号值得跟踪。
首先，@usedotai 已发布（56 个赞、4 条回复、1,614 次浏览）将基准测试凭证和训练来源信息与 Dot Reflex 一同发布，这一点很突出，因为它提高了模型/控制器发布的证据门槛。如果更多开放智能体发布可重放轨迹，而不只是权重和分数，可靠性讨论应该会少很多空谈。
其次，@OpenRouter 正在发布（138 个赞、8 条回复、11,164 次浏览）推出支持 1M 上下文窗口、常开推理并定位于长周期工程任务的开放权重 GLM-5.3，表明面向智能体编码的模型选择仍在扩张，而非收敛。这一点很重要，因为许多工厂模式的帖子假设的是多模型技术栈，而不是单一赢家。
第三，@josevalim 已发布（51 个赞、4 条回复、3,400 次浏览、19 个收藏）介绍了一个有意避免额外框架开销的设计画布，这是对“为智能体叠加更多抽象层”趋势的显著反向信号。这表明，一些构建者认为最佳的智能体 UX 往往是最简单、且尽可能贴近真实文件的界面。
7. 机会在哪里¶
[+++] 面向智能体运营的工作流状态层 —— Eve、Dot Reflex、Praxist 以及 Google Cloud 运维智能体的讨论，都再次强调了同一个需求：在更长时间运行的智能体工作流中提供类型化步骤、持久状态、重试机制、权限和幂等执行。
[+++] 智能体工厂评分卡 —— 当天关于基准测试凭证、开放权重长上下文模型以及重证据 harness 设计的帖子，都指向一个控制平面：衡量成本、质量、回滚风险、缓存性能和识别后弃用时间，然后将失败转化为可执行的 harness 改进。
[++] 面向智能体的证明与委托 SDK —— OpenWater 的真人证明方向以及 TermiX 式信任层，都表明市场需要一套可复用的软件包，用于身份、授权凭证、托管、证明选择和争议处理。需求是具体的，但市场似乎仍处于早期阶段。
8. 要点¶
- 讨论上移了一层。 软件基本功、评测设计和架构判断，比单纯打磨提示词更重要。
- 智能体买方越来越把 harness 当作操作系统来评估。 缓存经济性、云端执行、遥测和改进闭环，与模型封装本身同样重要。
- 关于可靠性的讨论越来越重证据。 相比基准测试最终分数，轨迹、控制器和过程指标的分量更重。
- 信任基础设施仍然活跃，但核心问题变得更明确。 讨论已经从智能体能否进行交易，转向每项行动需要什么证明、权限和审计轨迹。