Twitter AI Agent - 2026-10-10¶
1. 人们在讨论什么¶
1.1 验证的重点从“它答对了吗？”转向“它是否让世界处于正确状态？”（🡕）¶
2026-10-10 最明显的变化是，Agent 的可信度不再主要取决于编排层面的口号，而是越来越取决于明确的检查机制。最有分量的内容，不再争论 Agent 能不能采取行动，而是在讨论如何验证行动、如何评估就绪度，以及如何把执行与审查分开。当天至少有四条高质量内容在推动这一方向。
@sermakarevich 发帖（244 次点赞、30 条回复、14,182 次浏览、456 次收藏）简短提到了“agentic evals”，而回复串给出了关键证据：在作者的示例中，只看回复内容的评分器在 60 次运行中通过了 58 次，但在核验最终状态、必需工具、禁用工具和步骤预算后，重建状态检查只通过了 48 次。这让当天最有力的评估性判断变得非常具体：回复再流畅，也可能掩盖“什么都没做”或外部效果失灵的问题。
@tom_doerr 分享了（117 次点赞、5 条回复、6,374 次浏览、119 次收藏）提到了 Loop Engineering 仓库，其自称是一个模式库，用于发现工作、将其交给 Agent、验证结果并持久化状态。附带截图之所以重要，是因为它在一张图里展示了该项目的运行姿态：快速开始命令、从仅生成报告到更高自主性的分阶段发布路径，以及一个示例就绪度评分，而不是笼统的“自主”承诺。
@PrimeIntellect 宣布了（47 次点赞、1 条回复、3,600 次浏览、17 次收藏）称 Prime Agent 的 Rust 重写版和开源版本已经上线，而链接的 Prime Intellect 博文 补充了具体机制：planner、implementer、reviewer 和 verifier 角色；TUI、harness、protocol 和功能层面的对等性检查；以及在实现功能对等后继续进行性能爬坡优化。链接的 Prime Agent 仓库 现将该产品定位为一个可自我改进的 RLM harness，具备持久化 REPL 状态和内置 subagents，这也让讨论重点落在运行时与验证设计上，而不是 prompt 措辞。
@kmeanskaran 写道（41 次点赞、3 条回复、1,156 次浏览、23 次收藏）称，一个仍在开发中的 ML harness 使用了 skeptic agent，让人类参与关键决策、对模型做版本管理，并在 Agent 于后台编写代码时保持日志可见。即便仓库尚未公开，截图已经让这一说法足够清晰：一次运行显示了 7 个 Agent 角色、45 次工具调用、273k 个 token，以及一条长达 21.4 分钟的 trace；另一次则显示，一个被提升为正式版本的 logistic-regression 版本，在每 1,000 份申请的 loss 指标上优于已退役的 random-forest baseline。
讨论洞察： 最有力的反驳并不是反对 Agent，而是否定浅层评分。回复里有人追问，评分看的是最终答案还是外部效果，而目前公开场合中最好的回答是：状态比文字更重要。
与前一天的对比： 2026-10-09，公开测试版动态工作流的发布让“编排”成了焦点。到了 2026-10-10，讨论则从“多个 Agent 可以协同工作”收束到“把 verifier、scorer 和 state diff 给我看”。
1.2 记忆成了一个生命周期问题：保存、加载、复核与遗忘（🡕）¶
第二个强势主题是，人们已不再把 Agent 的记忆仅仅当作“更多上下文”来讨论。信号更强的帖子把记忆视为一个运营生命周期：哪些内容应保留在活跃上下文里，哪些该索引到别处，哪些必须在之后重新验证，哪些又应该过期。三条独立线程汇聚到了同一个观点。
@undefinedKi 提出（81 次点赞、19 条回复、5,079 次浏览、115 次收藏）指出，coding agents 会因为把原始工具输出直接塞进上下文而浪费 token，随后提到了 Context Mode，其 README 写道，sandbox tools 会把原始数据留在上下文之外，在 SQLite/FTS5 中跟踪编辑和决策，并支持 17 个客户端。附带截图提供了超出推文本身的有用证据：一次 React 文档搜索将 46.3 KB 保持为沙箱中的索引数据，只向活跃上下文窗口返回了 8.8 KB，可见摘要显示该流程节省了 81% 的上下文。
@0xwhrrari 发帖（88 次点赞、28 条回复、19,194 次浏览、85 次收藏）提出了一个紧凑的“AI 记忆栈”框架：保存什么、加载什么、复核什么，以及何时遗忘。链接的 X 文章无法抓取，但回复本身已经足以保留这一条目：一条回复说，加载时必须检查有效性；另一条说，只追加式记忆会让过时事实永远压过新事实；第三条则说，没有时间戳和来源的记忆不过是流言。
@witcheer 分享了（89 次点赞、9 条回复、3,470 次浏览、147 次收藏）提到 Reddit 上一个运行了六个月的 Hermes Agent 配置：只有重要事实会保留在对话记忆中，其余内容转移到 vault 或 skill；每晚由 cron 清理 skills 和 memory；另有仅运行脚本的独立任务负责每日、每周和每月备份。这一点之所以重要，是因为它把记忆描述为一种后台维护工作，而不只是模型上下文。讨论洞察： 关于记忆，最有价值的讨论焦点不是召回，而是新鲜度。多条回复反复强调时间戳、过期机制，以及在执行操作前重新核对源状态。
与前一天对比： 在 2026-10-09，context-mode 主要指向压缩和沙箱化。到 2026-10-10，讨论已扩展到陈旧记忆的失效模式、夜间清理，以及明确的“遗忘”策略。
1.3 语音与客服代理已从演示阶段走向运营（🡕）¶
另一个显著变化是，语音代理不再主要被当作吸睛演示来讨论，而是被更多视为涉及隐私、路由和故障处理的运营系统。最有力的证据来自一条具体的部署帖子，以及一则协议与产品公告。
@bandholz 写道（30 个赞，7 条回复，2,533 次浏览，50 次收藏）称，Beardbrand 大约用两天时间搭建了一个用于客户服务的 AI 电话代理，并将其设为公司的主要客服热线。这条帖子细节异常丰富：语音部分使用 xAI Voice Agent Builder，成本为每分钟 8 美分；Shopify 和 Recharge 运行在一个小型 Cloudflare Worker 之后；采用两级身份核验；涉及私密操作时使用六位数验证码；验证失败时静默处理；多次尝试后锁定；用 draft-order 结账链接替代电话支付；以及在 Shopify admin 内设置了一个仪表板，记录每通来电的处理结果和验证状态。
@mati 发帖（62 个赞，14 条回复，3,541 次浏览，12 次收藏）称，语音代理给其他语音代理打电话时，仍然不知道对方到底是谁，随后又提到 ElevenLabs 新推出的合成语音检测，以及 Personal Agent Protocol 相关工作。链接中的 ElevenLabs 博文 表示，ElevenAgents 会在最初几秒内将来电者判定为人类或 AI，然后按业务规则进行路由；而该工作组的目标，则是定义代理应如何表明自身身份、代表谁，以及被允许执行哪些操作。
讨论洞察： 这里有价值的回复模式并不是炒作。ElevenLabs 那条帖子下有回复指出，检测出合成语音，仍然无法证明来电者拥有什么权限；另有回复追问，语音代理在完成身份识别后，握手过程是否应切换到更高效、机器可读的通道。
与前一天对比： 在 2026-10-09，身份与边界控制还主要停留在协议和检测概念层面。到 2026-10-10，同一组问题已经出现在真实客服热线、具体验证流程，以及明确的队列路由逻辑中。
1.4 关于代理技术栈的讨论已下探到硬件、内核与服务经济性（🡕）¶
当天的第四个主题是，一些最具体的代理讨论其实发生在代理运行时本身之下。构建者和运营者把成本、吞吐量、内核行为和发布基础设施都视为代理工程的一部分，而不是独立的一层。
@sgl_project 报道（67 个赞，6 条回复，5,145 次浏览，20 次收藏）称，SGLang 已在 NVIDIA Vera Rubin 上针对 Kimi K3 推理和 Miles RL 训练进行了调优。链接中的 LMSYS/RadixArk 帖子 给出了具体数字：在 128k 上下文、batch 16 下，MLA decode 提速 16%；在 batch 1、128k 上下文下，FP8 MLA 提速 20%；融合后的 MoE tail 优化带来 5.9% 的端到端提升；以及在 Vera CPU 上运行 64 个并发沙箱，在 SWE-bench Verified 上进行 agentic RL。
@suraj_sharma14 发帖（170 个赞，12 条回复，6,251 次浏览，288 次收藏）是一份 12 阶段的“AI 基础设施工程”路线图，内容从 CUDA、KV-cache 数学和服务引擎，一直延伸到量化、投机解码、NCCL/RDMA、GPU 调度器，以及路由/可观测性。最有价值的一条回复进一步收紧了这个框架：一旦推理变得更便宜，成本往往会转移到搜索、抓取和数据补全等外部调用上，因此真正该关注的数字，变成了每个完成任务的成本，而不是每 token 成本。
讨论洞察： 基础设施类帖子呈现了当天最清晰的成本表述。它们认为，代理质量与服务、缓存和外部调用预算的底层约束密不可分。
与前一天对比： 在 2026-10-09，harness 和框架特性还是工具层面的主要叙事。到 2026-10-10，公开证据又向下延伸了一层，进入了内核、发布系统，以及维持代理持续运行的成本结构。
2. 什么让人感到挫败¶
只看输出的评分方式，仍会让有缺陷的代理看起来像是成功的¶
这是当天最尖锐的挫败点，同时出现在明确的评测讨论和构建者工具之中。@sermakarevich 报道（244 个赞，30 条回复，14,182 次浏览，456 次收藏）显示，仅按回复内容评分的方案在 60 次运行中通过了 58 次，而按重建后的状态评分的方案只通过了 48 次；失败案例里，系统会在根本没有退款发生时判定已经退款。@PrimeIntellect 指出（47 个赞，1 条回复，3,600 次浏览，17 次收藏）指向 planner/implementer/reviewer/verifier 循环和对等性测试套件，@tom_doerr 重点介绍了（117 个赞，5 条回复，6,374 次浏览，119 次收藏）则主张构建按就绪度评分的循环工具包，而不是依赖提示词技巧。人们目前靠重建状态、比对行为差异、将编写者与审阅者分离来应对，但这一需求依然非常迫切。值得构建：高。
Agent 记忆仍会退化为过时事实、臃肿上下文，或两者兼有¶
这些关于记忆的讨论暴露出一种很实际的失效模式：agent 记住了太多内容，却没记住那些仍然为真的部分。@0xwhrrari 描述了（88 个赞，28 条回复，19,194 次浏览，85 次收藏）提到了截止日期被替换的问题，回复中则主张加入时间戳、来源追踪、过期机制，以及在加载时重新验证。@undefinedKi 推广了（81 个赞，19 条回复，5,079 次浏览，115 次收藏）提出 Context Mode，作为一种让原始输出不进入上下文、同时保留可索引会话状态的方式；而 @witcheer 分享了（89 个赞，9 条回复，3,470 次浏览，147 次收藏）则展示了一种可行模式：vault、skills、清理任务，以及纯脚本备份。如今的权宜之计更多是运维工作：sandbox、cron job、vault，以及手动维护记忆卫生。值得构建：高。
语音 Agent 若缺少分层验证，可能越权或泄露数据¶
Beardbrand 那条讨论把这种挫败感具体化了。@bandholz 表示（30 个赞，7 条回复，2,533 次浏览，50 次收藏）提到，客服热线的早期版本在用户提供了错误的身份信息时，竟然读出了另一位客户的姓名和邮箱，这迫使系统重新设计：简单查询需要两项信息匹配，私密操作则要求六位数邮箱验证码，同时采用静默失败和锁定机制。@mati 补充说（62 个赞，14 条回复，3,541 次浏览，12 次收藏）指出，即便系统能检测出合成语音，也仍然无法证明来电者被授权执行哪些操作。构建者目前的应对方式，是把 AI 来电导入受限流程，并在 agent 与记录系统之间加入一个确定性服务层。值得构建：高。
真正该盯的成本目标是已完成的工作，而不是原始 token 价格¶
这些基础设施讨论表达了对过度简化的成本叙事的不满。@suraj_sharma14 梳理了（170 个赞，12 条回复，6,251 次浏览，288 次收藏）谈到了从 CUDA 和 KV-cache 数学，到路由和可观测性的整套技术栈；其中一条回复认为，一旦推理足够便宜，search 和 enrichment 之类的外部调用反而会成为更大的成本项。@sgl_project 支持了（67 个赞，6 条回复，5,145 次浏览，20 次收藏）则用公开的 Rubin 调优结果呼应了这种情绪：这些优化在 kernel 层面降低了 decode 和 verify 的开销。当前的应对方式包括面向特定硬件的调优、缓存、批处理和更好的路由，但讨论表明，许多团队可能仍然缺少一个清晰的“单个成功任务成本”控制界面。值得构建：高。
3. 人们希望看到什么出现¶
可复用的评测系统：评估最终状态、工具使用情况和可重复性¶
最强烈、也最务实的诉求，是一种能经受真实执行检验的评估方式。@sermakarevich 说明了为什么只评答案的评分器还不够，而 Loop Engineering 和 Prime Agent 都指向了可复用的验证脚手架，而不是一次性脚本。人们想要的似乎不只是“基准测试”，而是一套工具：能够重建环境、检查副作用、衡量执行路径，并且可在不同工作流中复用。机会：直接。
知道哪些内容仍然为真的记忆系统¶
这些关于记忆的讨论并不是在要求更大的上下文窗口。他们要的是带有来源、时间戳、过期机制和清理能力的记忆系统。@0xwhrrari 将问题概括为：决定哪些内容该保存、加载、复查和遗忘；而 @witcheer 则揭示出一种运维模式：每晚清理，并使用非 LLM 备份。Context Mode 在检索和压缩方面部分回应了这一问题，但这里的诉求更广：需要一个记忆层，能在智能体据此行动之前识别信息是否已经过时。机会：直接。
可跨渠道流转的智能体身份与授权¶
围绕语音智能体的帖子表明，在检测与执行之间缺失了一层。@mati 指向这样一种未来：智能体能够表明自身身份并协商能力边界；而 @bandholz 则显示，如今的开发者仍需自行拼装双层验证、邮件验证码和故障处理规则。这一需求很实际、很紧迫，也已部分由 ElevenAgents 路由和自定义中间件覆盖，但这个领域看起来更像是竞争激烈，而非尚未开垦。机会：竞争型。
与任务完成情况和系统行为挂钩的成本控制¶
基础设施层面的讨论指向一个更隐性的诉求：仪表盘和路由器应优化“成功完成工作”，而不只是压低 token 成本。@suraj_sharma14 强调了路由、调度和可观测性；@sgl_project 则表明，在智能体真正进入业务工作流之前，人们仍需在解码速度、kernel 启动和 rollout 效率上投入大量精力。现有 serving stack 和自定义路由器已给出部分答案，但产品层面的核心需求，仍是把模型成本、工具成本和任务结果统一到一个地方。机会：竞争型。
4. 在用工具与方法¶
| 工具 | 类别 | 倾向 | 优势 | 局限 |
|---|---|---|---|---|
| Context Mode | 上下文与记忆层 | (+/-) | 对原始工具输出做沙箱隔离，在 SQLite/FTS5 中保留会话状态，支持多种编程智能体客户端 | 节省效果的说法来自项目自身公开材料，且需要配置 hook/路由 |
| Loop Engineering | 循环与验证工具包 | (+) | 就绪度评分、从仅报告到更高自治级别的分阶段上线、明确的安全与故障模式文档 | 它是模式库，不是一键式 worker；仓库也警告 token 成本可能暴涨 |
| Prime Agent | 智能体运行时与 harness | (+) | 持久化 REPL 状态、内置子智能体、自我改进的 harness 模型、由对等性驱动的重写证据 | 要把它运转好似乎相当依赖基础设施，公开性能证据也主要由构建者自行提供 |
| xAI Voice Agent Builder | 语音智能体平台 | (+/-) | 在 Beardbrand 的构建中部署迅速，且每分钟成本较低；语音交互自然 | 认证和密钥处理仍需自定义中间件；不宜直接信任其执行敏感操作 |
| Shopify + Recharge + Cloudflare Worker | 记录系统中间件 | (+) | 让凭证不暴露给智能体，可实现受控查询与修改，并适配现有支持栈 | 需要定制胶水代码和谨慎设计验证规则 |
| ElevenAgents synthetic voice detection + Personal Agent Protocol | 身份与路由 | (+) | 早期来电分类和有边界的路由策略；明确朝智能体身份标准迈进 | 检测本身并不能建立授权；落地仍主要由企业推动 |
| SGLang + Miles on Vera Rubin | 推理与 RL 基础设施 | (+) | 公开了 kernel 级加速和 agentic RL rollout 证据；面向硬件的细节扎实 | 硬件相关复杂度高，调优负担重 |
| Hermes 风格的 memory vault、skills 和 cron cleanup | 运营方法 | (+/-) | 将活跃事实与归档内容分离，并加入清理和备份纪律 | 更多是社区实践分享，而非标准化产品 |
总体来看，大家更认可那些能约束智能体、保留状态或让故障可检查的方法。常见的权宜模式，是在智能体外再包一层更薄、更确定性的系统：用沙箱处理工具输出，在模型与 Shopify 之间加一个 Worker，在代码变更周围加显式验证器，并用 cron 作业维护记忆卫生。
主要迁移趋势，是远离以 prompt 为中心的控制方式。被持续保留下来的能力，反复转向 harness、索引化状态、中间件，以及可度量的运行时行为。竞争最激烈的三个方向是：上下文与记忆控制、语音智能体身份与路由，以及长时运行智能体下方的 serving stack。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Beardbrand AI 电话智能体 | @bandholz | 在 Beardbrand 主客服热线中处理产品指引、订单查询、订阅操作和升级转接 | 在无需配备传统呼叫中心人手的情况下提供电话支持，同时对敏感操作保留验证 | xAI Voice Agent Builder、Shopify、Recharge、Cloudflare Worker、Google Workspace | 已上线 | 推文 |
| Prime Agent Rust 重写版 | Prime Intellect | 用 Rust 重写 Prime Agent，并使用 planner、implementer、reviewer 和 verifier 智能体 | 提升长时运行智能体工作的运行性能、可靠性和可维护性 | Rust、持久化 Python 控制环境、Prime Sandboxes、GLM-5.3、对等性测试套件 | 已上线 | 推文, 博客, 仓库 |
| Context Mode | mksglu | 对工具输出做沙箱隔离，并为会话事件建立索引，让智能体恢复工作时减少上下文浪费 | 防止编程工作流中因压缩导致的“失忆”和上下文窗口膨胀 | TypeScript MCP server、hooks、SQLite、FTS5 | 已上线 | 推文, 仓库 |
| Loop Engineering | cobusgreyling | 为重复性智能体循环提供模式、starter、评分和运行规则 | 帮助团队围绕自主工作定义验证、状态和升级机制 | TypeScript CLI、模式库、就绪度评分、审计/成本命令 | 已上线 | 推文, 仓库 |
| ElevenAgents 合成语音检测 | ElevenLabs | 检测合成来电者，并对真人与 agent 采用不同的路由方式 | 让企业能在敏感操作发生前，对 AI 来电者加上边界约束 | 语音检测、路由规则、参与 Personal Agent Protocol | Beta | 推文, 博客 |
Beardbrand 的方案之所以格外突出，在于它展示了完整的集成模式，而不是躲在 demo 背后：前端是一层语音层，中间是确定性的 Worker，后端则是作为记录系统的商业系统。最重要的设计选择并不是语音本身，而是决定把密钥和私密操作放在模型可接触界面之外。
Prime Agent、Context Mode 和 Loop Engineering 也都体现出第二种反复出现的模式：开发者交付的不只是 agent 本身，而是围绕 agent 的控制平面。验证闭环、就绪度评分、持久记忆和受限发布级别，都被当作产品功能来对待。
ML harness 原型又补充了第三种模式：垂直型 agent 系统。它的截图显示，agents 会产出人类确实可以批准发布或拒绝的工件，这表明“agent 团队”类产品可能会先在狭窄的运营领域落地，而不是先成为通用型自主同事。
6. 新内容与值得关注的动向¶
具备状态感知的评测成了公开讨论话题，而不再只是内部运维习惯¶
@sermakarevich 披露（244 次点赞，30 条回复，14,182 次浏览，456 次收藏）指出了仅基于回复的评分与基于重建状态的评分之间存在的具体差距，而这条讨论也让更广泛的 Twitter 受众能够直观看懂这种区别。这一点值得关注，因为它推动 eval 讨论从基准测试式的氛围，转向副作用、所需工具、禁用工具和可重复性等运营问题。
垂直型 agent harness 开始展示实时操作员界面¶
@kmeanskaran 分享 展示了一个 ML 工作流（41 次点赞，3 条回复，1,156 次浏览，23 次收藏），其中 agents 会分析数据、做特征工程、比较模型版本，并向人工展示日志和发布选择。这一点值得关注，因为这些截图展示的内容比“一个 agent 团队”更具体：它们展示了版本化输出、评估指标，以及一个可见的交接点。
Agentic RL 出现在硬件 bring-up 和推理内核工作中¶
@sgl_project 联系到 公布了在 Vera CPU 上使用 64 个并发沙箱、基于 SWE-bench Verified 进行 agentic RL 的内核调优结果（67 次点赞，6 条回复，5,145 次浏览，20 次收藏）。这一点值得关注，因为这里的 agent 工作不再只关乎应用 UX 或编程助手；它也成了验证新型服务与训练基础设施的一种工作负载。
AI 电话客服从实验走向主线路¶
@bandholz 表示 表明 Beardbrand 的 AI 电话 agent 现在已成为公司的主要客服线路，而不是一个边缘渠道（30 次点赞，7 条回复，2,533 次浏览，50 次收藏）。这一点值得关注，因为这次部署包含了测试期间发现的隐私问题、明确的补救措施，以及一条受限升级路径，而不是那种在难点出现前就结束的 demo。
7. 机会在哪里¶
[+++] 具备状态感知能力的评估与验证产品 —— 证据横跨第 1、2 和 5 节：在公开讨论中，基于重建状态的评分胜过仅基于回复的评分；Prime Agent 的重写依赖明确的等价性测试套件；Loop Engineering 则把就绪度评分和分阶段自主性作为卖点。这个机会很强，因为多个开发者正在独立地围绕不同的 agent 系统构建同一层能力。
[+++] 记忆新鲜度、压缩与生命周期治理 —— Context Mode、关于 AI 记忆栈的讨论串以及 Hermes 的设置都指向同一个需求：决定哪些内容要保持活跃、哪些要建立索引、哪些要重新核查，以及哪些要退役。这一机会很强，因为这种痛点同时出现在高层理论和日常运维实践中。
[++] 面向商业与服务场景的安全语音 agent 中间件 —— Beardbrand 的客服线路和 ElevenLabs 的合成语音路由都表明，市场需要一层把身份识别、授权、升级处理和记录系统集成结合起来的能力。这个机会中等，因为已经可以看到明显的产品进展，但当前方案仍然高度依赖定制策略和胶水代码。
[++] 面向可重复运营工作流的垂直型 harness —— ML 团队 harness 和 Prime Agent 重写都表明，具有明确指标和人工检查点的狭窄领域，比起开放式“什么都做”的 agents 更容易落地。这是一个中等机会，因为工作流形态已经很清晰，但大多数公开案例仍处于早期，或仍由开发者自行运行。[+] 已完成任务成本可观测性 —— 基础设施相关讨论表明，出现了一种新的需求：需要在同一个控制面中统筹服务效率、外部调用成本和任务成功率。这一方向还处于起步阶段，尚未成熟，但围绕路由、批处理和外部调用预算的表述已足够频繁，值得关注。
8. 要点¶
- 围绕 agent 的验证，正在成为真正的产品界面。 当天最有力的证据并不是更大的模型或新的人设提示词，而是围绕重建状态评分、对等测试套件和就绪度评分的公开讨论。(来源)
- 如今，记忆质量意味着新鲜度和检索纪律，而不只是更大的上下文窗口。 Context Mode、关于 memory stack 的讨论，以及 Hermes 的配置，都强调了时间戳、索引检索、清理和遗忘。(来源)
- 语音 agent 正在变成具备鉴权、隐私和路由规则的运营系统。 Beardbrand 的客服热线和 ElevenLabs 的合成语音路由都表明，真正困难的部分是对动作的治理，而不是让 agent 听起来更自然。(来源)
- agent 技术栈正在向下延伸到服务内核和 RL 基础设施。 SGLang 和 Miles Rubin 的工作都将 agentic 工作负载视为优化解码内核、推测式验证和沙箱吞吐量的理由。(来源)
- 最可信的构建者，正在围绕 agent 交付控制平面。 Prime Agent、Loop Engineering 和 ML harness 展示的都是审查者、怀疑机制、评分、可见日志或晋级门槛，而不是不受约束的自主性。(来源)