Twitter AI Agent - 2026-06-19¶
1. 人们在讨论什么¶
1.1 编码代理工作区正在变成真正工作的操作系统（🡕）¶
最强的产品主线并不是某个新模型，而是编码代理环境正在变成完整的工作平台：包括代码仓库准备、仪表盘、插件、技能，以及终端内更丰富的渲染能力。至少有三条有力信息支撑这一主题：Grok Build 扩展为多会话工作区、Ramp 的内部 inspect 技术栈，以及 Matt Pocock 的公开技能仓库。
@XFreeze 报道称（1,657 个赞、276 条回复、456,309 次浏览、172 次收藏）称，Grok Build 已从编码 CLI 扩展为原生终端代理工作区，支持感知 AGENTS.md 的上下文、技能、钩子、插件、MCP 服务器、并行子代理、无头模式，以及用于管理阻塞、空闲和活跃会话的 Agent Dashboard。其独特之处不只是工具更多，而是终端本身拥有了更丰富的渲染层：Mermaid、UML、ER 图、LaTeX、表格和媒体输出现在都可以直接保留在工作流内，不必再复制到其他应用。
@rahulgs 表示（141 个赞、5 条回复、22,101 次浏览、194 次收藏）称，Ramp 的内部代理 inspect 现在产出了公司超过 75% 的代码。这条信息的重要性在于，它具体说明了实现这一点所依赖的条件：预装依赖、节省 token 的技能、沙箱快照、Terraform 计划、并行浏览器测试代理、在沙箱中更快运行的 mypy、人类与 AI 的审查闭环，以及针对不同模型和推理级别的明确成本优化。他在回复中补充说，工程师如今很少还需要在本地检出分支，因为云环境已经覆盖了过去通常需要手动完成的工作。
@mattpocockuk 已发布（233 个赞、11 条回复、8,996 次浏览、164 次收藏）发布了 mattpocock/skills 的 v1，包括 /ask-matt、由模型调用与由用户调用的技能，以及一份公开的技能编写指南。公开的 代码库 将这一套件描述为“真正工程师的技能”，重点放在对齐、TDD、领域建模和仓库配置上；截至采集时，该项目在 GitHub 上获得了 136,958 个星标。
讨论洞察： 最有价值的细节并不在愿景层面，而在运营层面。Ramp 的回复主要聚焦于仓库配置，Grok Build 的一条回复则称，该产品现在可以把过去旧版 Grok 开发界面做不成的任务“一轮完成”，这表明环境质量开始变得和模型质量一样重要。
与前一天比较： 6 月 18 日已经显示，多模型路由和可安装技能正在成为常规配置。6 月 19 日更进一步，把编码代理工作区本身视为产品：会话管理、插件系统以及预先配置好仓库的云环境，正在成为新的基线。
1.2 Loop 与 harness 工程成为严肃自主性的通用语言（🡕）¶
第二条主线是，信息流已经超越提示词技巧，转向模型外部的 loop：人工兜底、评测、上下文纪律和明确的 harness 设计。最有力的证据来自一家公开运营历程的日程安排公司，以及一位从业者关于 harness 构建者实际在优化什么的讨论。
@awwstn 报道称（123 个赞、16 条回复、43,111 次浏览、103 次收藏）称，他的邮件日程安排代理在经历多年迭代后，自动运行占比已超过 50%。这个领域里，一次糟糕的互动就可能损害潜在客户、投资人或候选人的信任。帖子给出了少见的具体细节：公司建立了人在回路中的兜底机制，将该团队扩展到 75 人，创建合成黄金数据集，并先后尝试微调、RL、ACE、DSPy 和子代理，最终才达到这样一个阶段：在一次自动运行实验中，150 家客户即便减少了人工干预，产品使用量反而更高。
@Vtrivedy10 认为（34 个赞、3 条回复、2,780 次浏览、55 次收藏）称，harness 工程的核心在于模型—harness—任务匹配、评测与轨迹，以及为每个子任务保持干净的上下文窗口。这条讨论补充了当天最清晰的从业者术语：harness 是模型行为的控制器和放大器；模型在 harness 内并不是可随意替换的；优秀的 harness 也不是第一次就能设计正确，而是通过基于轨迹的迭代逐步摸索出来的。
@traversymedia 提出异议（41 个赞、14 条回复、3,344 次浏览）在讨论整个“loop engineering”浪潮时表示，这个领域已经进入炒作周期中的一个阶段：旧概念被重新命名，又被重新发现。这种怀疑很重要，因为它避免了当天最流行的梗看起来像是普遍共识。
讨论洞察： 最可信的谨慎声音来自关注生产环境的人，而不是反 AI 发帖者。在日程安排讨论中，成功标准是信任和更低的流失率，而不是新奇感。在 harness 讨论及相关 loop 讨论中，人们不断回到评测、预算消耗，以及当一个 loop 无法可靠判断自己已失败时会发生什么。
与前一天比较： 6 月 18 日把记忆、技能和路由视为可安装的基础设施。6 月 19 日则向外再延伸了一层，转向决定这些组件如何被协调与监督的 loop 和 harness。
1.3 私有与本地代理从偏好变成部署模式（🡕）¶
第三条主线是，私有和本地执行不再主要被描述为一种意识形态，而是运营模式。相关证据既包括活动人士的部署，也包括兼容 OpenAI 的私有推理网关。
@gladstein 写道（298 个赞、26 条回复、42,100 次浏览、174 次收藏）称，HRF 和 Finite 已从 OpenClaw 实验走向活动人士的实际使用，包括一种“私有”模式——推理服务商无法读取用户数据；一种由团队自行控制的本地集群模式；以及一个运行在约 4,500 美元设备上的无审查模型，可供约十余人开展研究。该讨论还将本地化和私有化推进与具体部署目标联系起来：由 TEE 支持的前沿模型访问、原生运行于手机的加密代理应用，以及最终由内部记录和会议构建的组织级“头脑”。
@ErikVoorhees 显示（173 个赞、20 条回复、14,367 次浏览、53 次收藏）展示了通过 Venice 调用 GLM 5.2 的 Hermes Agent，把注重隐私的编码代理使用描述为一种实用配置，而不是研究玩具。Venice 公开的 API 文档 介绍了一个兼容 OpenAI 的 API，支持私密聊天、图像、音频和视频，并明确推广与 Claude Code、Cursor 和 Codex CLI 的编码代理集成。
讨论洞察： 最难解决的问题仍然是信任。一条针对 Erik 讨论的回复问道：即使 API 宣称私有，服务商是否仍能从上下文中识别私有代码的指纹？在 Gladstein 的讨论中，同样的担忧以另一种形式出现：整个战略目标就是减少对受 KYC 限制或存在政治暴露风险的前沿模型访问的依赖。
与前一天比较： 6 月 18 日已经显示，人们在代理技术栈中混用更便宜、更私密的模型。6 月 19 日新增了第一手部署细节、敏感用户场景，以及更明确的证据，表明团队正在为本地控制编列预算，而不只是讨论这一点。
1.4 代理商务与安全转向外部授权和证明（🡕）¶
最后一条主要趋势是，构建者不再相信单靠提示词就能让代理在处理资金、钱包和代码变更时保持安全。他们正把审批、签名和验证移到独立的控制层。
@SuiNetwork 分享了（78 个赞、9 条回复、3,024 次浏览）介绍了 Seal 的一个代理商务 MPC 原型，将授权置于代理之外。讨论及回复说明了其具体机制：链上消费规则和类别检查、自托管钱包、MPC 委员会生成的一次性见证，以及针对超预算、错误商户和虚假类别行为的明确压力测试。
@circle 发布了（64 个赞、7 条回复、2,508 次浏览）展示了一个更简单但同样有用的商务案例：一个代理研究潜在客户、准备通话上下文、支付语音通话费用，并起草后续跟进内容，总成本约为 1.08 USDC。这张图片的重要性在于，它把“代理经济”式表述转化为一套逐项列出的工作流，并显示了明确的美元成本。
@OpenCovenant 认为（34 个赞、14 条回复、107 次浏览）称，编码任务需要运行后的证明，而不只是代理自己的说法，并展示了一张验证卡片，将已完成任务关联到确切的文件变更和加密证明。@svpino 补充说（43 个赞、13 条回复、3,591 次浏览、27 次收藏）介绍了一种硬件签名方案：代理可以通过 Ledger Nano Gen5 准备 Ethereum 交易，但执行仍需要人在设备上批准。
讨论洞察： 回复明确指出了其中的权衡。审批更安全，但会增加延迟。这就是为什么 Sui 强调上限和一次性规则，而 Ledger 讨论中的一条回复则称，即使是高速机器人，也需要有边界的策略，而不是每次操作都等待人工。
与前一天比较： 6 月 18 日的安全讨论集中于治理框架和控制理论。6 月 19 日则把讨论落到具体的钱包、支付、证明和签名机制上，将授权与模型本身分离。
2. 人们感到沮丧的地方¶
现实世界的自主工作流仍需要昂贵的兜底机制和严格的评测闭环¶
严重程度：高。@awwstn 表示（123 个赞、16 条回复、43,111 次浏览、103 次收藏）称，他的日程安排公司必须建立人在回路中的平台，并将兜底团队扩展到 75 人，产品才能安全地接近 50% 的自动运行占比。同一讨论还提到负毛利、围绕时区和日历规则的无穷边界情况，以及评测几周几乎没有进展。@Vtrivedy10 认为（34 个赞、3 条回复、2,780 次浏览、55 次收藏）称，harness 只能通过轨迹、评测和反复实验得到改进，而不是靠直觉。@neil_xbt 警告称（47 个赞、18 条回复、5,008 次浏览）称，当生产环境中的 loop 缺少 maker-checker 分工、持久状态、worktree、连接器以及运营者真正信任的验证器时，就会迅速烧掉预算。团队应对这一问题的方式，是让人类留在回路中的时间比营销文案暗示的更长，并将评测视为核心基础设施。这一方向值得投入，因为这种痛点同时被构建者和运营者反复提及，而不只是评论者的观察。
隐形上下文和薄弱的运行后检查，仍让代理故障难以解释¶
严重程度：高。@DanKornas 介绍了（3 个赞、5 条回复、252 次浏览）claude-tap，回应了一个具体痛点：当上下文不可见时，调试编码代理非常困难。公开的 代码库 称，它可以检查 Claude Code、Codex CLI、Cursor CLI、OpenCode、Kimi、Pi 和 Hermes 中的系统提示词、对话历史、工具 schema、工具调用、流式响应、token 使用量和请求差异；截至采集时，该项目在 GitHub 上有 1,872 个星标。@OpenCovenant 实现了（34 个赞、14 条回复、107 次浏览）则从验证角度表达了同样的抱怨：用户不应被迫相信代理所说的变更内容。人们正通过加入轨迹查看器、明确的证明层，以及运行结束后更完善的产物关联来应对。这一方向值得投入，因为它反映的是结构性故障模式：上下文不可见时，信任和调试都无法扩展。
安全的代理商务仍在自主性与审批摩擦之间权衡¶
严重程度：高。@SuiNetwork 展示了（78 个赞、9 条回复、3,024 次浏览）称，当前的钱包模式对代理构成安全风险，并以外部授权、消费上限、一次性见证以及商户和类别检查作为回应。@svpino 展示了（43 个赞、13 条回复、3,591 次浏览、27 次收藏）介绍了一套基于 Ledger 的流程：代理可以准备交易，但仍无法在没有人在设备上批准的情况下执行；一条回复立即指出，审批延迟是更快的交易型代理面临的阻碍。@circle 补充说（64 个赞、7 条回复、2,508 次浏览）称，即便是简单的潜在客户开发工作流，也已经横跨研究、语音、支付和后续跟进服务。目前的解决办法，是将更多策略置于代理之外，同时收窄代理可以自主执行的范围。这一方向值得投入，因为需求明确，但当前的控制界面仍在拖慢它们原本要保护的工作流。
隐私安全和本地技术栈正在改善，但仍要求用户承担更多复杂性¶
严重程度：中。@gladstein 报道称（298 个赞、26 条回复、42,100 次浏览、174 次收藏）称，HRF 和 Finite 现在为活动人士运行私有和本地版本，包括一套约 4,500 美元、供十余人使用的本地配置。这是进步，但也显然带来了运营负担。@ErikVoorhees 显示（173 个赞、20 条回复、14,367 次浏览、53 次收藏）介绍了通过 Venice 使用私有编码代理的路径，但回复立即质疑：私有代码是否仍可能被推理服务商进行指纹识别。构建者正混合使用本地控制、基于 TEE 的部署和兼容 OpenAI 的私有 API，而不是信任单一技术栈。这一方向具有中等投入价值，因为需求真实存在，但配置和信任负担仍然很高。
3. 人们希望存在什么¶
围绕自主操作的可信审批与验证层¶
最明确的实际需求不是“更聪明的代理”，而是让代理能够消费、签名或修改代码，同时不必单独信任模型本身的更安全方式。@SuiNetwork 显示（78 个赞、9 条回复、3,024 次浏览）通过链上消费规则和一次性 MPC 见证将授权外置；@svpino 显示（43 个赞、13 条回复、3,591 次浏览、27 次收藏）将人工审批保留在硬件签名器中；@OpenCovenant 认为（34 个赞、14 条回复、107 次浏览）则称，用户应能核验项目的确切变更，而不是相信运行结束后的声明。这是一个具有即时买方痛点的实际需求。机会：直接。
更好地观察 harness 实际发送和看到的内容¶
多条信息都指向同一个缺失工具：一种能够检查真实上下文，而不只是最终答案的方式。@DanKornas 披露了（3 个赞、5 条回复、252 次浏览）claude-tap，而公开的 代码库 称，它可以捕获系统提示词、对话历史、工具调用、token 使用量和请求差异。@alexjplaskett 发布了（17 个赞、2 条回复、542 次浏览、7 次收藏）介绍了一份 50 页的 编码代理安全论文，涵盖权限模式、沙箱、动态工作流和常见故障类别。这是一个已有早期解决方案、但仍相对开放的实际需求。机会：直接。
默认的仓库配置和可复用技能，让代理从第一天起就能工作¶
当天最强的采用案例来自那些减少配置阻力的人。@rahulgs 表示（141 个赞、5 条回复、22,101 次浏览、194 次收藏）称，Ramp 通过标准化仓库配置、工具和反馈闭环，将代理生成代码的比例提升到 75% 以上。@mattpocockuk 已发布（233 个赞、11 条回复、8,996 次浏览、164 次收藏）介绍了一个面向对齐、TDD 和领域建模的公开技能仓库；@tom_doerr 分享了（8 个赞、2 条回复、876 次浏览、14 次收藏）则介绍了一个 YouTube 技能代码库，其 README 为 OpenClaw、Hermes、Claude Code、Cursor 等添加了转录、搜索、频道和播放列表功能。这是一个实际需求，证据表明构建者已经在用时间为此买单，尽管未必总是直接付费。机会：直接。
面向敏感用户和组织的私有、主权化代理技术栈¶
这里的情绪需求和实际需求重合：用户希望获得能力，同时不交出数据、身份或访问权。@gladstein 将其定义为（298 个赞、26 条回复、42,100 次浏览、174 次收藏）将私有和本地代理描述为活动人士追求自由、反 KYC 的要求；@ErikVoorhees 使用了（173 个赞、20 条回复、14,367 次浏览、53 次收藏）则将 Venice 描述为 Hermes 的私有推理层。这对一部分真实用户具有实用价值，但本地、私有 API 和 TEE 路线之间已经存在竞争。机会：竞争性。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Grok Build | 编码代理工作区 | (+) | 感知 AGENTS.md 的上下文、插件、MCP、仪表盘、图表渲染、并行子代理 | 仍主要通过发布节奏和产品可靠性更新来呈现；最有力的证据来自变更日志和用户回复，而不是更深入的运营文档 |
| inspect | 企业云编码代理 | (+) | 仓库配置、Terraform 计划、浏览器测试代理、沙箱中的 mypy、成本优化，以及与本地工作流相近的云端体验 | 要达到其报告的质量，需要大量内部准备工作和环境标准化 |
| mattpocock/skills | 技能库 | (+) | 提供用于对齐、TDD、领域建模和配置的可复用工程工作流；公开传播范围大 | 增加了需要整理和调试的抽象层，尤其是在技能由模型调用时 |
| Venice API + GLM 5.2 | 私有推理网关 | (+/-) | 兼容 OpenAI 的私有 API、编码代理集成、支持 Hermes 风格的工作流 | 隐私声明仍面临指纹识别质疑；API 密钥和对服务商的信任仍属于成本的一部分 |
| Seal MPC / Ledger Nano Gen5 | 授权层 | (+) | 将审批和密钥托管移到代理之外；支持上限、预算、人工签署和自托管 | 审批步骤会增加延迟；高速工作流仍需要有边界的策略 |
| claude-tap | 可观测性 / 调试 | (+) | 本地轨迹查看、精确上下文检查、token 使用量，以及跨多个编码代理的请求差异 | 解决的是事后检查问题；团队仍需有纪律地根据轨迹揭示的内容采取行动 |
| Covenant | 验证层 | (+) | 将代理任务与确切的文件变更及加密证明关联起来，让用户能够核验结果 | 目前只有早期公开信号；从当天证据看，还看不到更广泛的生产使用 |
| youtube-skills / TranscriptAPI | 代理技能 + 外部数据访问 | (+) | 为 OpenClaw、Hermes、Claude Code 和 Cursor 提供转录、视频搜索、频道浏览和播放列表功能 | 依赖第三方 API 配置和额度；相比通用 harness，它解决的研究工作范围更窄 |
总体而言，人们更看好那些围绕模型增加结构、而不是直接取代模型的工具。最明显的迁移方向，是从调整提示词转向准备环境：仓库配置、技能、轨迹、评测、仪表盘和验证层如今才是实际杠杆。第二条迁移方向，则是从仅使用前沿模型，转向包含开放或私有模型网关的混合技术栈。最强的竞争并不是模型对模型，而是控制界面对控制界面：谁能为运营者提供最好的可见性、最安全的审批，以及成本最低且可接受的执行方式。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| inspect | @rahulgs | Ramp 内部使用的云端编码协作者，覆盖工程及其他知识工作任务 | 团队希望代理能够在真实代码仓库中“直接工作”，而不是因缺少依赖、反馈薄弱或环境缓慢而失效 | 云沙箱、git + gh 工作流、Terraform 计划、浏览器测试代理、mypy、实时语音输入 | 已发布 | 推文 |
| Howie | @awwstn | 基于邮件的日程安排代理，每天安排数千场会议，自动运行占比已超过 50% | 日程安排充满对信任敏感的边界情况，通用代理很容易处理不当 | 人在回路中的运营平台、合成黄金数据、微调、RL、ACE、DSPy、子代理 | Beta | 推文 |
| Finite / HRF 私有代理技术栈 | @gladstein | 面向活动人士、并最终面向组织的私有、TEE 支持和本地个人代理版本 | 敏感用户需要强大的代理能力，同时避免 KYC 暴露或服务商可读取的数据 | OpenClaw 基础、定制 Hermes 界面、私有推理模式、本地集群部署、计划中的 TEE harness 托管 | Beta | 推文 |
| mattpocock/skills | @mattpocockuk | 面向编码代理的公开技能包，重点是对齐、技能组合和可重复的工程实践 | 构建者希望获得可复用工作流，而不是每次会话都重新解释最佳实践 | skills.sh 安装器、Markdown 技能、TDD、grilling、领域建模 | 已发布 | 推文、代码库 |
| Covenant | @OpenCovenant | 将代理完成的任务与确切项目变更及证明产物关联起来的验证层 | 团队需要能够审计代理实际修改了什么 | 文件变更关联、加密证明、验证界面 | Alpha | 推文 |
| Seal MPC 商务原型 | @SuiNetwork | 面向 Sui 测试网上代理商务的授权层原型 | 基于钱包的代理需要安全消费，同时不把原始密钥控制权交给代理 | Seal MPC、链上 Move 策略、一次性见证、React dapp-kit | Alpha | 推文 |
inspect 和 Howie 是最强的构建信号，因为二者都超越了玩具演示，深入到了运营细节。Ramp 的讨论显示，环境准备、仓库标准化和额外反馈闭环，才是把云端代理变成协作者的关键；Howie 则表明，在对信任敏感的领域，自主性要变得安全，仍需要长时间的兜底机制、评测和策略学习。
Finite 的突出之处在于，它将代理设计应用于比信息流中其他项目规模更小、但风险更高的用户群体。Gladstein 的讨论首先强调的不是便利，而是隐私、主权和反 KYC 访问，这表明在一种构建模式中，部署方式本身就是产品理念的一部分，而不是包装细节。
这些规模较小的公开项目在战略上同样重要。mattpocock/skills、Covenant 和 Seal MPC 原型，分别封装了许多团队可能都需要的一层能力：可复用的工作流纪律、可验证的结果，以及代理之外的授权。这种围绕代理交付能力层，而不是构建一个单体代理的模式，是当天数据中最清晰、反复出现的构建主题之一。
6. 新鲜且值得关注¶
一份公开的编码代理安全白皮书终于完整梳理了端到端的威胁面¶
@alexjplaskett 发布了（17 个赞、2 条回复、542 次浏览、7 次收藏）介绍了一份 50 页的 AI 编码代理安全导论 白皮书。仅目录本身就很有信息量，因为它列出了运营者如今需要理解的具体威胁模型：权限模式、危险权限设置、沙箱安全、代理工具、提示词注入、远程上下文、MCP 和代理通信。正文指出，编码代理安全主要由权限模型和沙箱机制决定，并提到 Claude 的动态工作流目前不会在操作系统沙箱内执行。
专业技能正在成为真正的分发渠道，而不只是本地提示词技巧¶
@tom_doerr 分享了（8 个赞、2 条回复、876 次浏览、14 次收藏）介绍了一个用于搜索和转录的 YouTube 技能代码库，公开 README 称其通过 TranscriptAPI 为代理提供转录、视频搜索、频道浏览和播放列表提取功能。该仓库还记录了 OpenClaw、Hermes Agent、Claude Code、Cursor、Cline、Codex 等工具的安装路径。它值得关注之处，与其说是互动量，不如说是它明确将代理能力视为可移植、可安装的软件包。
7. 机会在哪里¶
[+++] 代理授权、验证与消费控制 — 同一天有多个方向的证据指向这一点。Sui 的 Seal MPC 原型将授权移到代理之外；基于 Ledger 的工作流在保留人工审批的同时将密钥留在机器之外；Circle 展示了代理直接用 USDC 支付多服务工作；Covenant 则主张为代码变更提供加密证明。机会很强，因为这些项目都源于同一种运营者担忧：模型不是存放最终权限的合适位置。
[+++] 面向编码代理的仓库配置、轨迹和反馈基础设施 — Ramp 的 inspect 讨论、Vtrivedy 的 harness 工程笔记、Dan Kornas 的 claude-tap 信号，以及 Matt Pocock 的技能仓库，都指向同一个尚未满足的需求：让代理一开始就拥有正确工具、正确上下文、正确评测和正确调试界面的环境。机会很强，因为团队已经在内部构建这些东西，而这通常意味着外部产品类别确实存在。
[++] 主权化和隐私保护的代理部署 — Gladstein 关于活动人士部署的讨论，以及 Erik Voorhees 对 Venice 的配置，显示出对本地、TEE 支持或服务商私有代理技术栈的真实需求。机会中等，因为这一问题对特定用户群体十分紧迫，但已经有多条架构路线在竞争解决它。
[+] 可安装的专业技能与数据访问包 — Grok Build 的插件市场、Matt Pocock 的公开技能和 YouTube 技能仓库都显示，代理能力正在被封装为可复用模块。机会正在形成，因为这种封装模式已经清晰，但分发最终会围绕市场、GitHub 仓库还是特定运行时的注册表展开，目前仍不确定。
8. 要点¶
- 6 月 19 日，编码代理市场把升级重点放在模型周围的工作区上。 Grok Build 的变更日志、Ramp 的 inspect 讨论和 Matt Pocock 的技能发布，都将环境准备、会话控制和可复用工作流层视为真正的产品界面。（来源）
- 严肃的自主性仍然意味着 harness 工程加上耐心，而不只是更好的提示词。 Howie 达到 50% 自动运行占比，依赖 75 人的兜底团队、合成数据和长期评测闭环；与此同时，harness 构建者不断强调轨迹和上下文纪律。（来源）
- 私有和本地代理执行如今是一种部署选择，而不只是哲学偏好。 HRF/Finite 描述了私有、本地和计划中的 TEE 支持版本在活动人士群体中的使用，Venice 则记录了面向编码代理的私有、兼容 OpenAI 的路径。（来源）
- 代理商务正迫使授权移到模型之外。 Sui 的 Seal MPC、基于 Ledger 的审批流程、Circle 的 USDC 工作流和 Covenant 的证明层，都以不同方式将执行与最终权限分离。（来源）
- 安全和可观测性正在成为编码代理周围的独立产品层。 NCC Group 白皮书、claude-tap 和 Covenant 分别回应了同一缺口的不同部分：用户需要了解代理被允许做什么、实际看到了什么，以及究竟修改了什么。（来源）