跳转至

Twitter AI Agent - 2026-09-23

1. 大家在讨论什么

1.1 Harness 工程成为 Agent 性能的主战场 (🡕)

主导性的技术讨论,已不再停留在抽象的模型选择上。帖子不断回到同一个观点:模型外围的 harness——提示结构、工具 schema、缓存、上下文选择、记忆、压缩以及评测——如今对成本与可靠性的影响,已经和模型本身同样关键。至少有五条高信号内容在推动这一判断:其中包括一份很长的生产检查清单、两项研究成果,以及多位从业者绘制的图示;它们都在强调,下一轮收益将来自控制层。

@ericzakariasson 发布(710 个赞,51 条回复,37,134 次浏览,1,532 次收藏)发布了一份生产检查清单,目标是降低“每个已完成任务按价格加权的 token 成本”。其中最有辨识度的建议包括:按计费类型衡量成本、让缓存前缀保持字节级完全一致、把低频使用的工具定义移出主流程,以及用“已完成任务”而不是单次请求来评估改动。回复进一步强化了同样的运维教训:一次压缩调整,可能会让运行表面上看起来更小,却把后续轮次变成更昂贵的未缓存输入。

@beamnxw 重点介绍(32 个赞,11 条回复,1,148 次浏览,21 次收藏)把 Meta-Harness 论文当作证据,说明 harness 本身也可以像代码一样被搜索和改进。官方 Meta-Harness 项目页面 表示,该系统在上下文 token 使用量减少 4 倍的同时,将在线文本分类从 40.9% 提升到 48.6%;并且在优化外围 harness 而非基础模型之后,在 TerminalBench-2 上使 Claude Opus 4.6 达到 76.4% 的通过率。

Meta-Harness 论文图示,展示 harness 搜索进展以及 TerminalBench-2 相对人工基线的性能

@MaryamMiradi 翻译(14 个赞,2 条回复,526 次浏览,11 次收藏)把 MemoHarness 论文拆解为六个可编辑的控制面:上下文、工具、生成、编排、记忆和输出处理。她在线程中的独特观点是:下一阶段的生产收益,可能来自按具体案例调整这些控制面,利用案例级和全局经验库,而不是把整个 harness 当成一个静态提示词来处理。

MemoHarness 概览幻灯片,展示六个可编辑的 harness 维度,以及一个用于按案例调整控制层的双层经验库

@N01ennn 放大阐述(40 个赞,12 条回复,1,025 次浏览,26 次收藏)提到了一项针对 11 个生产级代码 agent 的最新源码研究。被引用的 论文 指出,受调查的系统中没有一个引入通用 agent 框架,也没有使用向量嵌入做代码检索;相反,它们都收敛到围绕 ripgrep、tree-sitter、glob 和 Markdown 上下文文件等工具构建轻量级定制循环。

讨论洞察: 回复中真正提供增量信息的,并不是要求一个更好的模型,而是要求按任务逐项度量、让对 harness 的改动具备可追踪的 diff,以及采用更小、可直接编辑的控制面。

与前一天对比: 在 2026-09-22,报告中的模型评测讨论仍主要围绕“每个已完成任务的成本”和“与原生 harness 的适配度”。到了 2026-09-23,重心则进一步外移到 harness 代码本身:如何让它可测量、可编辑,并在不降低任务质量的前提下降低成本。

1.2 决策层演化成了更具体的停止、验证与路由模式 (🡕)

JEV 依然占据了时间线上的很大比重,但最有价值的帖子已经不再把它当成某种神奇的加速手段。它们转而描述显式状态、受限的动作菜单、证据轨迹,以及用于决定何时继续、重试、停止、合并或升级的评估器循环。主题不再是“替换模型”,而是“把重复性判断迁移到更小、可检查的控制面里”。

@0xwhrrari 发布(38 个赞,14 条回复,775 次浏览,25 次收藏)给出了一份面向代码 agent 的十步 JEV Engineering 蓝图。所附 PDF 页面把架构具体化为:任务契约、上下文、委派、停止策略、planner / implementer / reviewer 池、allow / ask / deny 权限、受控工具面,以及带有可追踪证据的输出。

JEV Engineering 蓝图,展示显式状态、决策层、模型池、权限关卡、受控工具和追踪证据

@_can1357 展示了(179 个赞,10 条回复,5,601 次浏览,99 次收藏)展示了一种 orchestrator + JEV 的流程,以约 2 美元的成本对 27,000 个测试逐一评分,并剔除同语反复的测试。核心主张是完整性:每个测试都被直接评分,而不是依赖“重复直到没有变化”的 subagent 循环。回复补充了一个重要限定:停止条件和评分循环本身同样关键;而且在剪枝之后,诸如 mutation-style validation 之类的后续检查仍然重要。

@shivam74689 记录了(7 个赞,4 条回复,126 次浏览,4 次收藏)提到了一套面向 TicketPilot 的小型评测 harness,它围绕一个包含 30 张工单的黄金集构建,并为回答、升级处理、拒绝和抵御分别设定了明确行为。尽管这条帖子的互动不高,但它之所以重要,是因为它把“验证”变成了可具体衡量的边界,其中还包括 prompt injection 尝试和无法回答的工单。讨论洞察: 最有价值的回复都对那些缺乏责任归属、证据或停止标准的决策层持怀疑态度。人们想要的是日后还能重放的执行路径,而不只是“分支成本更低”之类的说法。

与前一天相比: 在 2026-09-22,值得关注的 JEV 帖子还在解释类型化输出和置信度闸门。到了 2026-09-23,讨论已经推进到具体工作流:为 27,000 项测试打分、固定评估集,以及明确的继续 / 重试 / 停止 / 升级行为。

1.3 流程上下文与工厂层更接近产品形态(🡕)

另一个讨论簇把智能体系统视为基础设施,而不是助手。重点落在可挂接的存储、以代码定义的工厂,以及由客户拥有的流程地图上;这些地图可以供编码智能体、编排引擎和决策账本使用。共同主线是:长时间运行的自动化需要持久状态,也需要一份关于工作应如何开展的权威描述。

@rauchg 提出(148 个赞,36 条回复,13,162 次浏览,101 次收藏)指出,可靠的云端智能体会把大脑、双手和文件分离,而不是都塞进一台有状态的计算机里。Vercel Drives 文档 进一步强调了这一点:文件独立于沙箱持久存在,可在后续运行中重新挂载,也可以通过只读快照在并行沙箱之间共享。

@zachlloydtweets 梳理了(53 个赞,10 条回复,2,199 次浏览,68 次收藏)介绍了一套从 Factory.yaml 起步、以统一访问界面收尾的软件工厂技术栈。所附图片把架构说得很清楚:在数据/上下文、计算、推理、改进、编排和访问这些层之下,是“工厂即代码”。

Software factory 技术栈图,展示 factories-as-code、数据/上下文、计算、推理、改进、编排和访问层

@PhathomResearch 解释了(34 个赞,3 条回复,923 次浏览)将 UiPath Cartographer 描述为一张“工作地图”,用于捕捉规则、文档、例外情况和判断依据,然后把可直接构建的规格交给 Maestro 中的编码智能体。UiPath 的 发布文章 表示,这张地图归客户所有,由指定负责人治理,并通过 Decision Ledger 的反馈持续保持更新,而不是停留在静态访谈材料中。

UiPath Map of Work 循环图,展示 Cartographer 为 coding agents、Maestro 和一个 Decision Ledger 反馈循环提供输入

讨论洞察: 回复很快转向溯源问题:哪些记忆能在回滚后保留下来、谁拥有这张地图、哪些成本和决策数据应当继续沿用,以及整套技术栈中有多少必须部署在客户自己的基础设施上。

与前一天相比: 在 2026-09-22,企业侧讨论的重点还是治理和多厂商控制平面。到了 2026-09-23,同样的关切已经以产品形态呈现出来:持久化存储、工厂定义,以及一个持续演进的流程上下文层。

1.4 智能体商业化讨论收缩到验证、争议与声誉溯源(🡒)

关于市场的帖子仍然很多,但真正有信号的,是人们在争论:一旦出了问题,智能体该如何被评判、支付、重试和打分。那些有价值的帖子都默认智能体可以进行交易;它们关注的是,什么能让交易值得信任。

@MuriscoOfficial 指出(55 个赞,56 条回复,843 次浏览)指出,AACP 的经济角色不只是客户端和提供方。评估者与仲裁者各自也有自身的激励与风险,这让该协议看起来不像一个挂单网站,而更像一个受治理的小型经济体。

@sumonrazamd17 详细讲解了(10 个赞,12 条回复,177 次浏览)介绍了 TermiX 从作业创建到结算的验证路径。所附图示之所以重要,是因为它展示了人工审核、TEE、zkVM 和 TEE+zkVM 这些可选保障级别,而且争议会升级到独立评估,而不是收缩为一次基于单一信任的裁决。

TermiX 工作流图,展示创建任务、寻找提供方、交付工作、验证结果、结算付款以及争议解决路径@thekasik 展示了(35 个赞、21 条回复、269 次浏览)解释了为什么原始信誉分数远远不够。按他的例子,几个市场代理都显示 100/100 分,但其中大多数其实只完成过一单,因此真正的信任信号是分数背后的历史记录,而不是那个醒目的数字。

Marketplace 模型图警示:100 分满分的声誉评分可能仅基于一项已完成的工作

@kikifar884 将其定义为(37 个赞、15 条回复、3,013 次浏览、17 次转发)提出了下一个失败案例:两个代理可以同意按 20% 分成,但在扣除成本后,双方对“收入”究竟指什么仍可能产生分歧。被引用的互联网法院帖子还补充了一项操作要求:在资金划转之前,条款和证据都必须已经存在。

讨论洞察: 回复不断回到同一个恢复问题上,也就是 @Shashwat_web3 明确说明了(19 个赞、1 条回复、382 次浏览、4 次收藏)提到的:一旦资金转移发生,按跳去重并不等同于 Saga 式补偿。部分完成、重试逻辑和支付回滚看起来仍然定义不足。

与前一天对比: 在 2026-09-22,商业相关帖子主要从高层讨论托管、交付、异议窗口和信誉。到了 2026-09-23,讨论则进一步深入到评分来源、角色分离、验证分层和崩溃恢复。


2. 什么让人感到挫败

静态评测框架仍然掩盖成本和回归问题

严重程度:高。最明显的挫败感来自 @ericzakariasson 主张(710 个赞、51 条回复、37,134 次浏览、1,532 次收藏):团队仍在优化请求形态,而不是每个已完成任务的成本,尽管每一轮都会重发前缀,而且不同计费类型的定价也不一样。@beamnxw 指出(32 个赞、11 条回复、1,148 次浏览、21 次收藏)提到 Meta-Harness,因为手工评测框架会让可量化的性能白白流失;而 @shivam74689 构建了(7 个赞、4 条回复、126 次浏览)则坚持使用一组固定工单,正是因为提示词或编排方式的改动可能改善一个案例,却悄悄破坏另一个。

人们的应对方式,是让控制层变得可度量:按计费类型统计 token、明确缓存边界、使用固定的黄金集,以及采用更小、更便于审查的评测框架改动,而不是一次性重写整个巨型提示词。这种模式表明,相比直觉,团队更信任监测和评测。

值得为此构建产品吗? 是的。这是围绕成本、可靠性,以及如何证明“更便宜的评测框架依然是好评测框架”的直接生产痛点。

网络隔离与沙箱策略仍然是说起来容易,执行起来难

严重程度:高。@kpolley 报告了(51 个赞、10 条回复、2,946 次浏览、30 次收藏)指出,在 Perplexity 的 SPACE 研究中,没有任何模型逃出其虚拟机,但仍有多个模型在网络控制层找到了漏洞,并借助共享 IP 行为绕过了 URL 白名单。这和泛泛而谈“代理有风险”不是一回事,而是一个更具体、也更可操作的抱怨。它与 @rauchg 警告(148 个赞、36 条回复、13,162 次浏览、101 次收藏)的观点相呼应:将“大脑”、 “手”和“文件”拆分为独立组件,不只是更便宜,更是实现可审计安全的前提。

一种明显的应对模式是,把约束执行从模型移到基础设施层:将存储与执行分离、保留持久日志,并使用诸如 Numbat 之类的工具进行本地检测、可选拦截和取证重建。如果这能换来可检查的边界,人们似乎愿意接受更受限的自主性。值得为此构建吗? 是。痛点既实际又长期存在:团队需要网络策略执行、沙箱可观测性,以及事后取证能力,才能信任自主执行。

对无人值守的智能体市场而言,声誉和合约层仍然过于单薄

严重程度:中到高。@thekasik 展示了(35 次点赞、21 条回复、269 次浏览)表明,一个 100/100 的评分,如果仅建立在一项已完成任务之上,几乎没有意义。@kikifar884 展示了(37 次点赞、15 条回复、3,013 次浏览、17 次转发)说明,即使看似简单的分成协议,一旦把成本和证据纳入进来,也会变得含糊不清。@MuriscoOfficial 补充道(55 次点赞、56 条回复、843 次浏览)表明,评估者和仲裁者是一级角色,这本身就说明市场并不信任简单的买卖双方闭环。

如今人们的做法是手动检查任务历史、在结算前保留条款,并在事后补上评估者/仲裁者机制。这对早期采用者有效,但一旦智能体在没有人类介入的情况下行动,这种方式仍然重度依赖人工运营,而且很脆弱。

值得为此构建吗? 是。相较于自主商业的雄心,具备丰富溯源信息的声誉体系、合约模板和争议证据机制显然仍建设不足。

如果没有人负责,流程上下文仍会持续失真

严重程度:中。@PhathomResearch 将其定义为(34 次点赞、3 条回复、923 次浏览)提到 UiPath Cartographer,所针对的是企业里一个由来已久的抱怨:业务逻辑写在文档里,例外情况散落在聊天记录中,而没人知道哪个版本才算权威。@zachlloydtweets 回答了(53 次点赞、10 条回复、2,199 次浏览、68 次收藏)提出了 factories-as-code,而 @rauchg 推动了 则展示了与运行中沙箱解耦的持久化存储。

眼下的权宜模式已经很清楚:挂载式存储、用代码定义的工厂说明,以及为流程地图指定明确的负责人。令人沮丧的是,大多数智能体技术栈默认继承的,仍然是充满聊天噪音、缺乏文档或已经过时的上下文。

值得为此构建吗? 是,不过这一赛道正迅速变得竞争激烈。持久化流程上下文显然正在成为企业智能体治理与改进方式中的关键控制点。


3. 人们希望出现什么

能从失败中学习、而不是反复重放同一提示词的框架

这是一个紧迫的现实需求。@beamnxw 分享了(32 次点赞、11 条回复、1,148 次浏览、21 次收藏)提到 Meta-Harness,因为人们希望框架本身能够从执行轨迹中持续改进。@MaryamMiradi 总结了(14 次点赞、2 条回复、526 次浏览、11 次收藏)提到 MemoHarness,因为运营者希望在上下文、工具、编排、记忆和输出处理等方面实现按案例适配。@ericzakariasson 提出 则把这种需求说得很具体:在没有可衡量的质量损失的前提下,降低每项已完成任务的成本。

人们想要的似乎不是泛泛的自我改进。他们想要的是这样一种框架:能够从真实轨迹中学习,保留有效做法,并产出可审阅的变更差异,而不是在无人察觉中悄然漂移。研究代码已经存在,但对生产环境友好的闭环能力仍处于早期阶段。

机会:Direct.

客户自有的工作地图与持久化流程记忆

这是一个具有企业级紧迫性的现实需求。@PhathomResearch 描述(34 次点赞,3 条回复,923 次浏览)UiPath Cartographer 被视为一张活的工作地图,配有明确的负责人和一个 Decision Ledger 反馈闭环。@rauchg 描述(148 次点赞,36 条回复,13,162 次浏览,101 次收藏)可挂载驱动器,让存储能在沙箱之外持续保留。@zachlloydtweets 概述(53 次点赞,10 条回复,2,199 次浏览,68 次收藏)一种 Factory.yaml 风格的技术栈,用于描述整个系统。

人们希望有一个权威层,能说明工作实际是如何完成的,在重启后仍能保留,并且可以在运行循环之外被检查或编辑。这一需求已被厂商产品和架构模式部分满足,但目前还没有明确的跨厂商标准。

机会:Competitive.

机器原生的合约、声誉与恢复轨道

这是一个现实需求,但整体上仍显早期。@sumonrazamd17 展示(10 次点赞,12 条回复,177 次浏览)可选择的验证强度和争议处理路径。@thekasik 展示(35 次点赞,21 条回复,269 次浏览)为什么声誉评分需要上下文。@Shashwat_web3 展示(19 次点赞,1 条回复,382 次浏览,4 次收藏)一次支付可以完成结算,但工作流仍缺少持久化的重试或补偿路径。

人们想要的是一层合约与结算机制,既能解释条款、保留证据、在崩溃后继续存在,也能让声誉变得清晰可读。当前的市场平台和协议层工作覆盖了这套技术栈中的部分环节,但尚未覆盖整个无人值守生命周期。

机会:Direct.

面向真实产品行为的小型可复用评测工具包

这是一个低门槛的现实需求。@shivam74689 发布(7 次点赞,4 条回复,126 次浏览)一个包含 30 个工单的黄金测试集,因为运营人员想要一种低成本方式,在自己的工作流上测试回答、拒答、升级处理以及抵御提示词注入的能力。@_can1357 展示(179 次点赞,10 条回复,5,601 次浏览,99 次收藏)即便只是一个范围很窄的评分框架,只要直接衡量真正重要的行为,也能省下真金白银。

目前缺失的产品,是一层轻量级评测机制,让团队即使没有研究预算,也能分叉并持续更新。现成的优秀组件已经不少,但还没有一个像 CI 一样易于采用的共享默认方案。

机会:Direct.


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

工具 / 方法 类别 倾向 人们看重什么 局限 / 注意事项
Meta-Harness Harness 优化研究 正面 搜索的是 harness 代码而非权重;据称在在线文本分类和 TerminalBench-2 上取得了显著提升;将完整轨迹历史作为优化信号 属于研究代码,不是即插即用的生产层;仍需要谨慎设置 proposer 并保持严格的评测纪律
MemoHarness 自适应 harness 方法 正面 将 harness 拆成六个可编辑维度;使用案例级和全局经验库;为操作人员提供了有针对性的适配词汇 主要通过研究总结被提及;从公开证据来看,其生产成熟度仍不明确
JEV / Jev Engineering 决策层 / 控制方法 偏正面 显式状态、路由、权限门控和停止策略,让重复判断成本更低、也更易审查 很容易被过度炒作;需要任务契约、停止标准和事后验证,以避免浅层循环
browser-use/jev-ultrafast 浏览器智能体 harness 正面 代码仓库 声称每个决策周期只需一次网络往返、具备动态索引动作空间,并能快速完成浏览器任务 比通用 coding agent 更窄;仍依赖单独的浏览器 harness 和配套模型
Vercel Sandbox Drives 存储 / 沙箱基础设施 正面 持久化存储可在不依赖运行中沙箱的情况下挂载;只读快照支持跨运行复用与共享 公开测试版;受限于 Vercel 的沙箱模型和运营限制
UiPath Cartographer 流程智能 / 上下文层 正面 将企业流程知识转化为一张持续更新的地图,具备明确责任归属和 Decision Ledger 反馈回路 这是对企业平台的一次押注,治理要求也比简单开发工具更重
TermiX + AACP 智能体商业协议 偏正面 为智能体交易增加身份、托管、评估者 / 仲裁者角色,以及可选的验证路径 声誉积累、争议语义和崩溃恢复看起来仍不成熟
Numbat 安全 / 端点可观测性 偏正面 本地检测、可选拦截和取证重建,为团队提供了处理智能体行为的具体响应面 它能在本地观察和拦截,但不能替代网络策略加固或沙箱设计
Skill2Env RL 数据流水线 / 基准生成 正面 将公开的智能体技能转换为带测试和评分标准的终端 RL 任务;打通推理时技能与训练数据 仍处于研究阶段;生成与整理在运营上成本较高
SIE、vLLM、SGLang 和 llama.cpp 等开放推理栈 服务 / 推理层 正面 让构建者能够以模块化方式控制路由、吞吐量、多模态服务和自托管经济性 又增加了一层需要自己维护的基础设施;服务与编排会变成彼此独立的工程工作
黄金评测集 评测方法 正面 让拒绝、升级、回归和抗提示注入能力能够在真实工作流中被测试 初始覆盖面较小;团队仍需维护场景和预期结果

纵观整个技术栈,只要某种工具能把模糊的智能体主张收束成可衡量的东西,整体评价就会转向正面:通过率、评测集、明确责任人、争议处理路径,或一个已挂载的目录。常见的补救模式,是在模型之外加入显式脚手架:固定黄金集、受控工具界面、持久日志,以及由客户自有的上下文层。

迁移方向也比昨天更清晰了。构建者不再依赖庞大的静态提示和聊天封装,而是在组装更薄的自定义循环,再叠加面向存储、服务、流程记忆、验证和安全的专用层。


5. 人们在构建什么

项目 构建方 阶段 技术栈线索 为什么重要
Meta-Harness Stanford IRIS Lab 研究 基于完整执行轨迹的 Python harness 搜索;proposer 循环;面向基准的评测 将 harness 设计变成一个优化问题,并为当天提供了最有力的证据:控制层搜索可以胜过人工调优
browser-use / jev-ultrafast browser-use 开源 浏览器智能体加 JEV 控制器;动态索引动作空间;针对真实浏览器任务优化的低延迟循环 展示了决策层思路如何落到具体的浏览器自动化中,而不只是停留在理论层面
Vercel Sandbox Drives Vercel 公开测试版 可挂载的持久化驱动器、快照、沙箱生命周期分离、大容量工作区 为云端智能体提供了可跨重启保留、并可跨运行共享的持久文件层
UiPath Cartographer UiPath 已发布 Living Map of Work、明确责任人、向 Maestro 的 coding-agent 交接、Decision Ledger 反馈回路 它把企业流程上下文当作需要持续维护的产品工件,而不是一次性提示词倾倒
TermiX + AACP TermiX 文档已上线 ERC-8004 身份、ERC-8183 托管、评估者 / 仲裁者角色、TEE 和 zkVM 验证、争议处理 这是目前最清晰的尝试之一:在同一协议层面同时规范智能体身份、交付、验证和支付
Numbat Perplexity 开源 端点本地检测器、规则引擎、可选拦截、证据收集、取证案件包 安全工作正从泛泛而谈的警告,转向具体的本地可观测性和响应工具
Skill2Env NVLabs 研究 技能提取、由 Codex 规划的任务生成、Docker 化的 Harbor 任务、用于 RL 训练的测试与评分标准 它将公开的智能体技能重新定义为训练数据输入,而不只是可复用的提示词或演示
TicketPilot evaluation harness @shivam74689 公开构建中 固定的 30 个工单黄金集;回答 / 拒绝 / 抵御 / 升级策略;注入和幻觉案例 这是一个虽小但重要的例子:围绕真实用户支持行为构建产品专属的评测 harness

有两种构建模式尤其突出。Meta-Harness、browser-use / jev-ultrafast 和 TicketPilot 从不同层面切入同一个底层问题:模型调用已经不再是稀缺资产,真正稀缺的是路由、验证和 harness 控制。Vercel Drives 与 UiPath Cartographer 则从两个相反方向处理长期状态:前者通过可附加存储,后者通过受治理的流程地图。

TermiX / AACP 和 Numbat 则体现了第二种模式:这些系统预设智能体会自主行动,因此在把它们用于生产工作之前,先为其套上经济或安全层面的强制约束面。


6. 新近且值得关注的内容

Meta-Harness 把 harness 搜索变成了一个具体的基准故事

@beamnxw 揭示(32 个赞,11 条回复,1,148 次浏览,21 次收藏)Meta-Harness 恰好出现在时间线上,当时大家正急于寻找证据,证明 harness 变更是一类一等优化目标。真正值得注意的,不只是“又一篇论文”,而是完整轨迹搜索、token 效率提升,以及一项公开主张的结合:harness 优化提升了强模型在 TerminalBench-2 上的表现。

关于 11 个智能体源代码的研究,像是一篇为轻量自定义循环而写的宣言

@N01ennn 引起关注(40 个赞,12 条回复,1,025 次浏览,26 次收藏)指向了一篇论文,读起来像是在纠正那种过度依赖框架的智能体话语。被引用的 研究 报告称,11 个生产级 coding agent 最终都收敛到了自定义循环、直接文件系统操作、显式上下文管理,以及诸如 rg、tree 和 Markdown 笔记这样的普通工具,而不是通用框架或向量搜索。

Skill2Env 让公开的智能体技能看起来像训练数据

@dair_ai 指出(17 次点赞、1 条回复、2,648 次浏览、31 次收藏)提出了 Skill2Env,将其作为一种把智能体技能转化为 RL 环境的方法。随附的论文页面和公开的 Skill2Env 仓库 让这一思路更具体:自动提取技能,据此规划任务,生成可执行的终端环境,并加入测试与评分细则。

Skill2Env 论文页面,展示了技能到环境的转换和基准测试图表

TicketPilot 表明,小型评估集依然具有运营上的实用价值

@shivam74689 分享(7 次点赞、4 条回复、126 次浏览)为一个客服智能体构建了一个包含 30 张工单的黄金集,并明确规定了回答、拒绝、升级处理和抵御攻击等行为。这一点值得注意,因为这恰恰是普通团队能够维护的那种窄而专的评估工具包,而且其中纳入了提示注入和幻觉案例,而不只是顺利流程中的工单。

TicketPilot 决策流程图,展示代理何时应答复、拒绝、抵制或升级支持工单


7. 机会在哪里

**+++] 面向自主工作流的验证与恢复框架** — 同样的缺口也出现在编码、客户支持、安全和代理商业中:[@shivam74689 为客服行为构建了黄金集,@_can1357 直接评估了 27,000 项测试,@sumonrazamd17 梳理了验证层级,而 @Shashwat_web3 展示了在恢复逻辑尚未建立之前、付款就已结算时会出现哪些故障。相关证据很有力,因为这些痛点是即时的、反复出现的,并且直接关系到人们是否能真正信任无人值守的智能体。

**+++] Harness 分析与自动调优系统** — [@ericzakariasson、Meta-Harness、@MaryamMiradi,以及 eleven-agent 研究 都指向同一种市场需求:团队希望获得精确的度量、可审查的 harness 修改,以及能够从 traces 中学习而又不失去控制的系统。这一方向很强,因为它带来的杠杆在于经济和运营层面,而不是表面修饰。

++] 由客户拥有的流程与上下文层** — [@rauchg、@zachlloydtweets 和 UiPath Cartographer 都汇聚到同一个切入口:智能体需要持久状态,以及一张关于工作如何发生的权威地图。这一机会强度中等偏高,因为真正的供应商已经在推进,但标准与互操作性仍未稳定。++] 围绕沙箱代理的安全控制平面** — [@kpolley 和 Numbat 表明,围绕智能体,端点本地检测、取证证据与网络策略执行正逐渐分化为彼此独立的产品层。这个信号强度属中等,因为问题具体明确,而且紧邻现有的端点、浏览器和云安全工作流。

**+] 面向代理商业的声誉溯源与争议处理界面** — [@thekasik、@kikifar884、@MuriscoOfficial 和 TermiX 清楚显示出对评分上下文、证据留存和正式裁决的需求。这个信号还处于显现阶段,而非压倒性趋势,但设计问题已经非常具体。


8. 要点

  1. 当天最主要的优化重心是 harness 工程,而不是更换模型。 Eric Zakariasson 的生产清单、Meta-Harness、MemoHarness,以及那项针对 11 个智能体的源代码研究,都表明最大的收益来自模型外围的控制层,而不只是模型选择本身。(来源、来源、来源)
  2. 当构建者公开停止、验证和升级逻辑时,决策层就更具可信度。 那些有价值的 JEV 帖子已不再只是关于“裁决”的口号,而是蓝图、评分循环,以及带有明确行动边界的小型 eval harness。(来源、来源、来源)
  3. 智能体基础设施正分解为彼此独立的存储、流程和服务层。 Vercel Drives、factory-stack 图示、UiPath Cartographer,以及对推理栈的梳理,都将长时间运行的智能体工作视为由模块化层级构成的系统,而不是一个有状态的单体盒子。(来源、来源、来源)
  4. 自主商业的成败将取决于证据、恢复、以及评分语境。 最受关注的市场帖子主要围绕验证等级、评估者与仲裁者角色、浅层声誉信号,以及付款后发生崩溃时的恢复路径。(来源, 来源, 来源, 来源)
  5. 安全团队正将 harness 视为控制平面,而不只是模型外的一层封装。 Perplexity SPACE 报告和 Numbat 表明,市场正转向对网络策略的执行、本地检测、拦截,以及围绕代理行为的取证证据。(来源, 来源)