Twitter AI Agent - 2026-05-17¶
1. 人们在讨论什么¶
1.1 Harness 工程正演变为课程、运营手册和成本核算 🡕¶
Harness 工程仍是最强的讨论集群，但相关证据已进一步从抽象架构讨论转向可复用的运营实践。信号最强的帖子并不是新的基准测试结论，而是一门公开课程、一套面向专用 Agent 的从原型到生产配方、一份详细的 harness 与框架映射，以及一手成本披露。至少有五项实质性内容共同支撑了这一主题，其中几项明确聚焦于如何让长期运行的 Agent 可观测、可治理且负担得起。
@_vmlops 分享（1,350 个赞、6 条回复、73,602 次浏览、2,216 个书签）称 学习 Harness Engineering 课程 是互联网上学习这一主题的最佳去处。网站称，该课程面向 Codex 和 Claude Code 风格的 Agent，讲解环境设计、状态管理、验证与可观测性。截图之所以重要，是因为其中的课程列表围绕连续性丢失、过早宣告胜利、缺乏可观测性等失败模式展开，而不是泛泛而谈的提示词技巧。
@shannholmberg 表示（148 个赞、14 条回复、12,007 次浏览、218 个书签）认为，生产环境中的 Hermes 专用 Agent 应先在主编排器中孵化，运行 4-10 次，反复修正直到跑干净，再部署为独立的 Docker 化 Agent。图片补上了缺失的运营细节：先完成原型，再迭代；必要时用 Claude Code 或 Cursor 进一步收紧；最后将生成的技能和脚本移植到一个边界清晰、拥有独立凭证和记忆的生产 Agent 中。
@FUCORY 称（117 个赞、6 条回复、14,762 次浏览、118 个书签）认为，Bun 的重写项目是现实世界中 Harness 工程的最佳案例之一。附图才是实质内容：它将 Bun 重写项目的组件映射到 Smithers 的原语，包括任务图、工作树、schema、重试、SQLite 输出、分叉/回放和差异工具；回复还补充了在更广泛讨论中很少被点名的两个具体 harness 思路——用于记忆处理的生命周期分类器，以及明确的背压设计。
@valentinmihov 报道（14 个赞、5 条回复、947 次浏览、7 个书签）表示，他所在团队的 harness 集合了 Multica 看板、运行在 Codex 上的 Hermes、Hindsight 记忆系统、内部监控、OAuth2 SSO、仅限 VPN 的运维访问，以及由 Git 管理的基础设施。截图把它转化为一份真实的运营预算：约 6 亿个 token、约 3,000 美元 API 支出，而他估计这相当于两个月的基础设施工作量。
@vipulgupta2048 追溯（12 个赞、4 条回复、581 次浏览、6 个书签）解释了为什么在编码 Agent 中简单说一句“hi”就可能花费约 8 美分，并称昂贵的并非提示词，而是每次请求都会一并携带的 27,000-token harness 缓存载荷。他的截图和讨论串将成本拆分为缓存写入、缓存读取、工具 schema、CLAUDE.md、技能、记忆子系统和启动调用，使 harness 经济学更像云基础设施计费，而非聊天定价。
讨论洞察： 最有价值的反驳来自已经在运行这些系统的人。@shannholmberg 下的一条回复提醒说，在混乱的生产数据到来之前，4-10 次受控运行可能会让 Agent 过拟合于 harness；而 @_vmlops 下的回复则反复强调，懂理论和把理论用于生产是两回事。这一天的讨论看好 harness，但并未轻视其中的工作量。
与前一天的比较： 5 月 16 日的 harness 讨论集中在可观测性论文、框架映射和成本披露上。5 月 17 日，同一话题进一步转向运营实践：课程、部署配方、成本追踪和明确的生产闭环。
1.2 技能和记忆正成为 Agent 真正的控制面 🡕¶
第二个讨论集群不再将 Agent 能力主要归因于模型选择，而是视为技能、记忆层、钩子和运行时集成的打包组合。Hermes 位于这一集群的中心附近，但更广泛的信号显然不止于某个运行时：人们正在传播架构图、自我演进的技能系统、与订阅绑定的能力，以及厂商官方技能包。
@akshay_pachaar 写道（75 个赞、13 条回复、6,471 次浏览、79 个书签）称，Hermes 最强大的功能不是聊天，而是自我演进的技能：Agent 解决一个难题后，会将有效流程保存为 SKILL.md，并在下一次会话中复用，而不是重新摸索工作流。该讨论串中的关键细节是：Hermes 还需要一个 Curator 进程来合并重叠技能、归档过时技能；同时，有回复指出，内置记忆在长时间会话中仍可能不一致。
@Teknium 宣布（330 个赞、54 条回复、39,165 次浏览、43 个书签）称，SuperGrok 和 X Premium+ 订阅现已可直接在 Hermes Agent 中使用。引用的 Nous Research 帖子及其回复明确展示了实际价值：Hermes 用户可通过 OAuth 路径继承 Grok 访问权限，以及 X Search、图像生成、视频生成和支持语音的流程，使这一运行时更像能力枢纽，而不只是一个仅依赖 API 密钥的外壳。
@PythonDvz 将其概括为（21 个赞、2 条回复、988 次浏览、18 个书签）将现代 Claude 技术栈描述为围绕模型展开的技能、MCP、子 Agent、钩子、工具和项目上下文。架构图让这篇帖子值得保留：它将这些控制面展示为真正的工作栈，也清晰呈现了如今许多构建者认为杠杆所在的位置。
@seelffff 声称（45 个赞、4 条回复、2,740 次浏览、25 个书签）指出，Google 现已推出官方 agent-skills 仓库，只需一条命令即可安装，其中列出了 BigQuery、Firebase、Cloud Run、GKE、Cloud SQL、Gemini API、AlloyDB，以及安全性、可靠性和成本优化技能。即使互动量不高，它也符合当天其他帖子的共同趋势：停止手动重写上下文，改为安装打包好的能力。
讨论洞察： 这一主题内部的张力在于维护。@akshay_pachaar 明确警告，Agent 创建的技能如果没有整理就会不断堆积；回复则指出，长时间会话中的记忆一致性仍然存在问题。社区希望拥有程序化记忆，但也清楚，不受控制的记忆和技能增长会带来新的清理难题。
与前一天的比较： 5 月 16 日强调操作员控制台和与服务提供商绑定的运行时界面。5 月 17 日延续了这一势头，但进一步转向打包技能、程序化记忆和官方技能库，将其视为扩展 Agent 的首选方式。
1.3 垂直 Agent 在金融、手机和安全领域变得更加具体 🡕¶
第三个明确趋势是垂直化。最有说服力的构建者案例不再是泛泛的“个人 AI”承诺，而是具有明确领域属性的应用：以文档为中心的金融工作、消费者支出分析 Agent、获得 root 权限的 Android 手机 Agent，以及基于浏览器的渗透测试系统。它们的共同点并不是为了新奇而追求新奇，而是把 Agent 嵌入既有的人类工作流，并让它在其中变得可理解、可审视。
@jerryjliu0 称（89 个赞、8 条回复、6,117 次浏览、128 个书签）将基于文档的金融 Agent 分为两类：发票处理、KYC 和贷款发起等重复性后台提取流程，以及用于尽职调查和股票研究的前台研究 Agent。图片进一步明确了这一划分，回复则点出了运营约束：在 KYC 和贷款流程中，静默提取错误、跨文档核对，以及可审计性不足，比答案不完整更危险。
@FundamentEdge 演示了（79 个赞、6,510 次浏览、133 个书签）介绍了一个消费者支出追踪 Agent。它使用更新的数据输入和监控面板，改进 Joseph Ellis 的消费能力框架。第一张截图是关键证据：其中展示了加权宏观分类，以及 -0.93% 的综合消费能力同比读数，将原本抽象的“金融 Agent”说法转化为具体的分析师工作流。
@OliverBaumgart 开源了（7 个赞、1 条回复、456 次浏览、9 个书签）介绍了 PocketDaemon。其 README 将其描述为一个实验性的 Android 原生 AI 手机 Agent，采用 Flutter 加 Android/Kotlin 服务构建，支持本地记忆、定时任务、手机工具，以及可选的基于 Magisk 的特权安装路径。在信息流中另一个安全色彩浓厚的角落，@tom_doerr 分享（2 个赞、132 次浏览）介绍了 Pentest Copilot。其 README 将其描述为一个基于浏览器的 AI 渗透测试 Agent，支持 Burp 集成、浏览器自动化、VPN 处理和后台子 Agent 并行运行。
讨论洞察： 金融领域的回复是这里最重要的质疑来源。在 @jerryjliu0 下，业内人士反复表示，难点不在于提取字段，而在于判断字段何时出现静默错误，并在人工签字前核对相互矛盾的文档。安全角度则带来了第二个警示：@Thionne_WTZ 使用了 借一篇 Hermes 深度分析提醒人们，虚假的“免费 Claude Code”仓库正在传播恶意软件；这说明 agentic 工具也正被用于供应链验证。
与前一天的比较： 5 月 16 日已通过仓库增长榜单和交易技术栈显示出金融领域的热度。5 月 17 日则增加了更扎实的工作流证据——文档流水线、仪表板、手机原生 Agent 和安全工具——使构建者生态显得更加广泛，也更偏向实际运营。
2. 什么让人感到沮丧¶
Harness 开销仍然高昂、有状态，而且很容易被低估¶
最明显的高严重性问题是，可靠的 Agent 仍然伴随着高昂的隐性运营成本。@vipulgupta2048 展示了（12 个赞、4 条回复、581 次浏览、6 个书签）指出，一句简单的问候在计入缓存写入、工具 schema、CLAUDE.md、技能、记忆和启动调用后，可能就会产生约 8 美分的成本。@valentinmihov 报道（14 个赞、5 条回复、947 次浏览、7 个书签）介绍了一个团队 harness：搭建它消耗了约 6 亿个 token、约 3,000 美元，尽管发帖者仍认为这比构建类似基础设施更便宜。@shannholmberg 介绍了（148 个赞、14 条回复、12,007 次浏览、218 个书签）指出，在专用 Agent 能够安全部署前，需要反复进行修正；有回复警告称，即使这些重复运行也可能让 Agent 过拟合于干净的 harness。严重性：高。当前可见的应对方式是尽量停留在长期会话中、保持 harness 上下文精简，并将 Agent 视为有状态服务，而不是廉价的函数调用。值得投入建设，因为运营者已经在要求更好的成本核算、回归问题可见性和 harness 纪律。
以文档为中心的 Agent 仍会在风险最高的环节失败¶
高风险文档工作流是少数几个回复持续提出比原帖更严格约束的领域之一。@jerryjliu0 称（89 个赞、8 条回复、6,117 次浏览、128 个书签）指出，金融 Agent 需要严格的 OCR、评估检查和 HITL 审核，因为即使轻微的数字错误，也可能在下游造成灾难性后果。回复进一步明确了失败模式：有人表示，提取质量不等于可审计性；有人认为，金融运营质量的真正标准是能否安全地取消人工复核；还有人指出，跨文档核对比解析任何单个文档都更加困难。严重性：高。当前的解决办法是增加审核、核对逻辑和明确的审计界面，而不是实现完全自动化。值得投入建设，因为这一痛点切实存在，业内人士反复提及，并且与已经足以支撑真实支出的工作流直接相关。
Agent 商务仍缺乏可信的结算与治理基础设施¶
最强烈的治理不满并不在于发现机会，而在于 Agent 采取行动之后会发生什么。@sijlalhussain 认为（14 个赞、2 条回复、327 次浏览、3 个书签）指出，Agent 商务的信任依赖身份验证、人工监督、透明度、数据安全和可问责的治理，而不是品牌宣传。在 @Unibase_AI 的 marketplace 帖子（20 个赞、76 条回复、101 次引用、31,917 次浏览）下，最有实质内容的回复表示，可组合的技能调用仍需要托管、交付物哈希和评估者结算，实际工作才能完成闭环。严重性：高。当前的解决办法仍是人工批准、人工覆盖或额外的链下协调。值得投入建设，因为市场启动速度已经超过了信任与结算基础设施的发展速度。
Agent 供应链已经嘈杂到让构建者公开相互警告¶
另一个规模较小但具体的痛点是，周边 Agent 生态中已经出现明显的安全陷阱。@Thionne_WTZ 警告（11 个赞、4 条回复、648 次浏览）指出，一个虚假的“免费 Claude Code”仓库属于正在进行的恶意软件活动；可见的 GitHub 源码只是诱饵，真正的风险在 ZIP 安装程序中。相关的 rosie 安全文档 从一般层面描述了同类问题：外部 Markdown 和技能可能携带恶意指令、标签重写或不可见字符注入，因此锁文件、移除注释和审计日志都被视为必要防御措施。严重性：中。当前的解决办法是优先选择官方渠道、固定引用版本，并明确审核第三方 Agent 内容。值得投入建设，因为这一警告已经是运营层面的，而非理论上的。
3. 人们希望有什么¶
不会腐化的持久程序化记忆¶
最明确的实际需求不是泛化记忆，而是能够在复用过程中保持有效、又不会变成杂物的流程记忆。@akshay_pachaar 将其定位为（75 个赞、13 条回复、6,471 次浏览、79 个书签）将 Hermes 技能视为 Agent 存储解决问题的确切步骤的地方，同时也承认必须有 Curator，才能避免技能库陷入重复和冗余。@tom_doerr 分享（12 个赞、3 条回复、1,584 次浏览、15 个书签）介绍了 miniclawd，其 README 还加入了持久记忆、cron 调度和子 Agent。机会：直接。人们需要的不只是回忆能力，而是可复用、经过整理的运营记忆，能够不断积累却不会变成维护负担。
面向受监管工作的可审计文档上下文 Agent¶
金融领域的讨论异常明确地展示了尚未满足的需求。@jerryjliu0 介绍了（89 个赞、8 条回复、6,117 次浏览、128 个书签）将当前技术栈描述为 OCR、评估和 HITL 审核，而回复不断强调，真正的阻碍是静默提取错误和跨文档核对。与其说这是对更智能模型的要求，不如说是对另一类系统的要求：系统必须能够证明提取了什么、核对矛盾之处，并向审核者准确展示证据来源。机会：直接。需求明确、痛点强烈，而现有文档流水线仍只能部分解决这一问题。
Agent 商务的结算、身份和覆盖层¶
商务领域的讨论不断回到同一个缺失的基础层：Agent 是谁，谁能够阻止它，以及如何验证已完成的工作。@sijlalhussain 称（14 个赞、2 条回复、327 次浏览、3 个书签）指出，信任依赖身份验证、人工监督、透明度、数据安全和可问责的治理。在 @Unibase_AI 的 帖子（20 个赞、76 条回复、101 次引用、31,917 次浏览）下，一条回复又补充了托管、交付物哈希和评估者结算。机会：直接且具有竞争性。需求十分具体，但多家市场已经在信任层尚未确定之前，自上而下地尝试填补这一空白。
私有、常驻运行并拥有现实世界权限的个人 Agent¶
另一个较为安静但真实存在的需求，是能够驻留在个人设备上、按计划行动，而不是只存在于浏览器标签页中的 Agent。@OliverBaumgart 发布了（7 个赞、1 条回复、456 次浏览、9 个书签）介绍了 PocketDaemon，其 README 将其描述为一个获得 root 权限的 Android 手机 Agent，支持通话、本地记忆、调度和手机工具。@tom_doerr 重点提到 则从桌面端展示了 miniclawd 的持久记忆和调度能力。机会：直接但小众。对于希望掌控本地环境的高级用户而言，这一需求很实际，但当前实现仍要求较高的技术配置，并需要用户明确信任设备级权限。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Learn Harness Engineering | 课程 / 参考资料 | (+) | 围绕编码 Agent 提供环境设计、状态管理、验证和可观测性的公开课程体系 | 仅提供教育材料；运营者仍需将其转化为自己的技术栈 |
| Hermes Agent | Agent 运行时 | (+/-) | 自我演进技能、持久化 Agent 工作流、Grok 订阅访问，以及专用 Agent 部署模式 | 用户仍报告长时间会话中的记忆不一致，以及技能泛滥后的清理工作 |
| Claude Code + harness stack | 编码 Agent 运行时 | (+/-) | 通过技能、MCP、钩子、子 Agent 和项目上下文实现强大的可扩展性 | 隐藏的缓存/引导成本可能主导小型交互的开销 |
| 官方技能仓库（Google skills、Anthropic skills） | 技能库 | (+) | 通过一条命令安装打包好的能力，无需为云服务工作流手写上下文 | 公众热情领先于明确的使用数据；技能仍需要整理和版本控制 |
| softaworks/agent-toolkit | 技能市场 / 库 | (+) | 拥有 1,844 个 GitHub stars，并为日常编码工作流提供大量可安装技能、Agent 和命令 | 增加了团队需要审核和维护的第三方内容层 |
| miniclawd | 个人 Agent 运行时 | (+) | 在轻量级 TypeScript + Bun 技术栈中提供多 LLM 支持、内置工具、Markdown 技能、持久记忆、cron 调度和子 Agent | 项目规模较小，目前公开的运营验证有限 |
| PocketDaemon | 移动端 / 手机 Agent | (+/-) | 在 Android 原生技术栈中提供手机通话、实时语音/聊天、本地记忆、日程和设备工具 | Rooted Android + Magisk 的要求使其更像研究级项目，而非大众产品 |
| TencentDB Agent Memory | 记忆层 | (+) | 提供分层本地记忆、token 减少，以及明确的回忆/深入检索路径；默认无需外部 API 依赖 | 插件配置和分层存储增加了运营复杂性 |
| TradingAgents | 金融框架 | (+/-) | 开源多 Agent 交易技术栈，结合分析师、情绪、投资组合和执行角色 | 回复仍质疑以情绪分析为主的 Agent 集群能否持续优于更简单的系统 |
| Pentest Copilot | 安全 Agent | (+/-) | 基于浏览器进行渗透测试，支持 Kali、Burp、浏览器自动化、VPN 处理和后台子 Agent | 仅限经授权的测试场景，运营复杂度高于主流编码 Agent |
总体而言，这一天对那些将能力外化为技能、钩子、记忆和明确运行时的工具持积极态度，而不是将行为埋在提示词中。最主流的解决方式是：用可安装的技能包替代手写上下文，用定时或持久化 Agent 替代无状态聊天，用可检查、可迭代的 harness 替代模糊提示。竞争焦点正从“最佳模型”转向“最佳周边系统”：更好的记忆卫生、更低的 harness 税、更安全的第三方技能引入，以及更具主张性的操作员界面。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Consumer Spend Tracking Agent | @FundamentEdge | 围绕消费者消费能力数据构建仪表板，并允许分析师调整校准参数和相关性 | 减少投资工作中维护宏观消费者支出框架的手工负担 | 未披露；仪表板 + 宏观和另类数据流水线 | Alpha | 推文 |
| miniclawd | FoundDream | 支持多 LLM、工具、技能、持久记忆、cron 任务和子 Agent 的轻量级个人 Agent | 为高级用户提供持久、可调度的个人 Agent，而不是被动响应的聊天窗口 | TypeScript、Bun、Markdown 技能、Telegram、Feishu | Beta | 仓库、推文 |
| PocketDaemon | @OliverBaumgart | 将获得 root 权限的 Android 手机变成语音/聊天 Agent，可接听电话、使用手机工具、保留本地记忆并安排任务 | 将具有本地状态和现实世界手机权限的 Agent 行为带到个人设备上 | Flutter、Android/Kotlin 服务、Magisk、Gemini/xAI providers | Alpha | 仓库、推文 |
| Pentest Copilot | Bugbase Security | 基于浏览器的 AI 渗透测试系统，可连接 Kali 主机、运行工具、检查结果，并通过子 Agent 迭代 | 自动化跨浏览器、代理和 Shell 界面的重复性渗透测试工作流 | JavaScript、Docker、Kali、Burp Suite、浏览器自动化、VPN 支持 | Beta | 仓库、推文 |
Consumer Spend Tracking Agent 脱颖而出，是因为截图展示了真实的分析师界面，而不是概念草图。它也是 5 月 17 日常见构建者模式最清晰的案例之一：利用现有的专家框架，接入更新的数据源，并自动化更新闭环，而不是从头发明新的工作流。
miniclawd 和 PocketDaemon 从不同方向指向同一个更广泛的趋势。miniclawd 将持久记忆、调度和子 Agent 打包进轻量级桌面/服务器式助手；PocketDaemon 则将同样的持久化理念推向手机，提供通话、笔记、日程和本地设备工具。反复出现的触发点是连续性：构建者希望 Agent 能够记忆、按时唤醒，并在受约束的环境中行动。
Pentest Copilot 在安全领域展现了同样的模式。其 README 强调自主执行命令、Burp 集成、浏览器自动化和后台任务并行运行，因此它更像是围绕专用环境构建的工作流引擎，而不是面向黑客的聊天机器人。
6. 新鲜且值得关注的内容¶
GitHub 正式确立“Agent 监督者”角色¶
@_vmlops 发布了（33 个赞、3 条回复、1,810 次浏览、28 个书签）指出，GitHub 已在 Beta 阶段推出 GitHub Certified Agentic AI Developer 认证。附图是核心证据：它直接列出该认证，并将重点放在软件生命周期中 Agent 的运营和治理上，而不只是使用助手。这使该帖子成为劳动力市场和职业专业化方面的重要信号。
一篇 Stanford 论文反驳“默认上多 Agent”¶
@rohanpaul_ai 总结了（4 个赞、838 次浏览、6 个书签）介绍了一篇 Stanford 论文。论文认为，在思考 token 预算相同的情况下，单个强模型通常能够在多跳推理任务中达到或超过多 Agent 系统的表现。这一点很重要，因为它为当天的讨论提供了一个针对热门编排方式的有益修正：更多 Agent 并不自动意味着更好，一些看似明显的提升可能只是测试时计算量增加的结果。
Codex 可能正在吸收实时语音和后台播报能力¶
@DevAdventur3s 报道（99 个赞、12 条回复、7,010 次浏览、25 个书签）称，OpenAI 似乎正在为 Codex 接入实时语音，由后台 Agent 处理编码工作，同时界面播报进度。第二张截图是关键的公开证据，因为其中展示了 Rust 代码路径中的 WebRTC、gpt-realtime-1.5、后台 Agent 交接和进度钩子，而不只是未经证实的传闻。
7. 机会在哪里¶
**+++］ Harness 成本与回归核算** —— 第 1 节和第 2 节从不同角度指向了同一个缺口：人们现在已经能描述如何构建 harness，但仍然难以对其进行定价、检查和控制。［@vipulgupta2048 把“为什么说一句 hi 也要花钱”拆解为缓存和启动成本，@valentinmihov 发布了完整的全栈成本披露，@shannholmberg 则描述了部署前的迭代负担。机会很强，因为这一痛点反复出现、成本高昂，而且与现有运营行为相关，而不是停留在未来猜想上。
**++］ 面向受监管运营、可审计的文档智能体** —— 金融领域的构建者已经在尝试自动化 KYC、贷款和研究工作流，但围绕 ［@jerryjliu0 的回复 一直强调，静默提取错误和核对失败才是阻碍实际落地的原因。机会中等至强，因为买方已经清晰可见，而且需求足够聚焦，可以围绕证据可追溯性、面向审核者的审计界面和跨文档矛盾处理来构建产品。
**++］ 技能与记忆的生命周期管理** —— ［@akshay_pachaar 希望程序化记忆能够不断积累；回复则希望它不会漂移或堆积；miniclawd 和官方技能仓库从另一个角度展示了同样的打包趋势。机会中等，因为生态显然正在转向可安装技能和持久化 Agent，但团队仍需要更好的整理、过期、测试和跨运行时移植能力。
[+] Agent 生态的信任与供应链保障 —— Agent 市场的发布速度已经超过结算逻辑的发展速度，围绕恶意“免费 Claude Code”克隆的安全警告也已经出现。因此，身份、托管、可审计性、签名技能来源证明，以及安全引入第三方内容，正成为新兴但重要的机会，尤其适用于运营公开市场或共享技能注册表的团队。
8. 要点¶
- Harness 工程在这一领域已经不再是小众研究术语，而是正在被教授、运营化并纳入成本核算。 信号最强的帖子是一门公开课程、一套生产配方和一手成本追踪，而不是对抽象模型的赞美。（来源）
- 真正占据主导地位的控制面，正从提示词文本转向技能、记忆、钩子和类似 MCP 的集成。 Hermes 的技能积累、厂商官方技能仓库以及 Claude 架构图，都指向同一个方向。（来源）
- 金融是最清晰的现实需求领域之一，但前提是 Agent 能够证明自己的工作。 金融讨论中充满了对 OCR 错误、静默提取错误和核对失败的警告，这意味着可审计性是产品本身，而不是锦上添花。（来源）
- 持久化 Agent 正进入具体场景：仪表板、手机和安全工具。 当天的构建者案例包括消费者支出仪表板、获得 root 权限的 Android 手机 Agent，以及基于浏览器的渗透测试系统。（来源）
- 这个领域仍在公开纠正自身的炒作。 一篇 Stanford 论文质疑默认采用多 Agent 的做法，而市场和安全讨论则不断提醒读者：更多 Agent、更多技能或更多集成，并不能消除治理与信任的必要性。（来源）