Twitter AI 智能体 - 2026-05-17¶
1. 人们在讨论什么¶
1.1 运行框架工程正在变成课程体系、操作手册和成本核算 🡕¶
运行框架工程仍是最强的讨论簇,但证据已经进一步远离抽象架构讨论,更贴近可重复的运营实践。信号最强的帖子不是新的基准测试宣称,而是一门公开课程、一套把专家智能体从原型推到生产的配方、一张细致的运行框架映射图,以及一手成本披露。至少有 5 条实质性内容支撑这一主题,其中几条还明确在讨论如何让长时运行的智能体变得可观测、可治理、可负担。
@_vmlops 分享了(1,350 次点赞、6 条回复、73,602 次浏览、2,216 次收藏)《Learn Harness Engineering》课程,并称它是互联网上学习这个主题最好的地方。站点介绍称,这门课会讲解面向 Codex 和 Claude Code 风格智能体的环境设计、状态管理、验证与可观测性;而截图之所以重要,是因为它展示的课程列表围绕的是连续性丢失、过早宣告胜利、可观测性缺失等失效模式,而不是泛泛的提示词建议。

@shannholmberg 认为(148 次点赞、14 条回复、12,007 次浏览、218 次收藏),生产级 Hermes 专家智能体应该先在主编排器里孵化,跑 4-10 次,反复纠正到干净,再部署成专用的 Docker 化智能体。配图补上了关键的操作细节:先做原型、反复迭代,可选地用 Claude Code 或 Cursor 继续打磨,然后把得到的技能和脚本迁移进一个边界清晰的生产智能体,让它拥有自己的凭据和记忆。

@FUCORY 表示(117 次点赞、6 条回复、14,762 次浏览、118 次收藏),Bun 的重写是现实世界里运行框架工程的最佳案例之一。真正有料的是附图:它把 Bun 重写中的组件映射到 Smithers 原语,包括任务图、工作树、模式、重试、SQLite 输出、分叉 / 回放以及 diff 工具;回复区又补上了两个在更广泛讨论里很少被点名的具体运行框架思路——用于记忆处理的生命周期分类器,以及显式背压设计。
@valentinmihov 透露(14 次点赞、5 条回复、947 次浏览、7 次收藏),他的团队运行框架整合了 Multica 看板、运行在 Codex 上的 Hermes、Hindsight 记忆系统、内部监控、OAuth2 SSO、仅限 VPN 的运维访问以及 Git 管理的基础设施。截图把这件事变成了真实的运营预算:大约 6 亿 token、约 3,000 美元的 API 开销,而他估计要是自己搭同等基础设施得花两个月。
@vipulgupta2048 拆解了(12 次点赞、4 条回复、581 次浏览、6 次收藏),为什么在编程智能体里一个简单的“hi”也可能花掉大约 8 美分,并指出贵的不是提示词,而是每次请求都会附带的那份缓存的 27,000 token 运行框架负载。他的截图和讨论串把成本拆成了缓存写入、缓存读取、工具 schema、CLAUDE.md、技能、记忆子系统和启动调用,让运行框架经济学看起来更像云基础设施计费,而不是聊天定价。
讨论要点: 最有价值的反驳,来自那些已经在运行这些系统的人。在 @shannholmberg 那条贴文下,有回复提醒说,4-10 次受控运行可能会在脏乱的生产数据到来之前,先把系统过拟合到运行框架上;而 @_vmlops 的回复区则不断强调,懂理论和把它用到生产里是两回事。这一天大家普遍看好运行框架,但对其中需要投入的工作量并不轻率。
与前日对比: 5 月 16 日,关于运行框架的讨论还集中在可观测性论文、框架映射和成本披露上。到了 5 月 17 日,同样的讨论已经更偏运营层面:课程、部署配方、成本追踪,以及明确的生产循环。
1.2 技能和记忆正在成为真正的智能体控制面 🡕¶
第二个讨论簇不再把智能体能力看成单纯的模型选择,而是把它看作技能、记忆层、钩子和运行时集成打包在一起的结果。Hermes 位于这个讨论簇的中心附近,但更大的信号不只属于某个运行时:人们在传播架构图、自进化技能系统、与订阅绑定的能力,以及厂商官方的技能包。
@akshay_pachaar 写道(75 次点赞、13 条回复、6,471 次浏览、79 次收藏),Hermes 最强大的特性不是聊天,而是自进化技能:智能体解决一个难题后,会把有效的处理过程保存成 SKILL.md,下一次会话直接复用,而不是重新摸索工作流。真正关键的细节也在同一讨论串里:Hermes 还需要一个 Curator 进程来合并重叠技能、归档陈旧技能,而一条回复则指出,内置记忆在长会话中仍可能不一致。
@Teknium 宣布(330 次点赞、54 条回复、39,165 次浏览、43 次收藏),SuperGrok 和 X Premium+ 订阅现在都可以直接在 Hermes Agent 里使用。被引用的 Nous Research 帖子和回复把具体价值说得很清楚:Hermes 用户可以通过 OAuth 路径继承 Grok 访问权限,以及 X Search、图像生成、视频生成和支持语音的工作流,这让这个运行时更像一个能力枢纽,而不只是一个只靠 API key 的外壳。
@PythonDvz 把(21 次点赞、2 条回复、988 次浏览、18 次收藏)现代 Claude 栈概括为围绕模型展开的技能、MCP、子智能体、钩子、工具和项目上下文。真正让这条贴文值得保留的是那张架构图:它把这些控制面展示成真正起作用的工作栈,也给出了一张清晰的公开快照,说明如今许多构建者认为杠杆究竟在哪里。

@seelffff 声称(45 次点赞、4 条回复、2,740 次浏览、25 次收藏),Google 现在有一个官方智能体技能仓库,可以一条命令安装,并列出了 BigQuery、Firebase、Cloud Run、GKE、Cloud SQL、Gemini API、AlloyDB,以及安全性、可靠性和成本优化等技能。尽管互动量不算高,它仍然符合当天其他帖子展示出的同一模式:别再手写上下文,而是安装打包好的能力。
讨论要点: 这个主题内部的张力在于维护。@akshay_pachaar 明确提醒说,若不加策展,智能体生成的技能会不断堆积;回复则点出了长会话中的记忆不一致。社区想要的是过程记忆,但也清楚,失控的记忆和技能增长会制造出新的清理问题。
与前日对比: 5 月 16 日强调的是操作台和与提供商绑定的运行时界面。5 月 17 日延续了这一势头,但又进一步深入到了打包技能、过程记忆和官方技能库,把它们视为扩展智能体的首选方式。
1.3 垂直智能体在金融、手机和安全场景里开始落地 🡕¶
第三个清晰模式是垂直化。最强的构建者案例不再是泛泛的“个人 AI”承诺,而是按领域塑形的东西:文档密集型金融工作、一个消费支出分析智能体、一个已 root 的 Android 手机智能体,以及一个基于浏览器的渗透测试系统。共同点不是为了新奇而新奇,而是把现有的人类工作流接住,让智能体在其中变得清晰可用。
@jerryjliu0 表示(89 次点赞、8 条回复、6,117 次浏览、128 次收藏),围绕文档的金融智能体大致分成两类:一类是发票处理、KYC 和贷款发起等重复性的后台抽取工作流,另一类是面向尽调和股票研究的前台研究智能体。图片把这种区分进一步讲清楚,而回复则明确点出了运营约束:在 KYC 和贷款工作流中,静默抽取错误、跨文档对账失败,以及缺乏可审计性,比答案只是“不完整”要危险得多。

@FundamentEdge 演示了(79 次点赞、6,510 次浏览、133 次收藏)一个消费支出追踪智能体,它用更新的数据输入和一个监控面板,把 Joseph Ellis 的消费能力框架现代化。第一张截图是关键证据:它展示了加权宏观分项,以及 -0.93% 的综合消费能力同比读数,让原本抽象的“金融智能体”说法变成了一个具体的分析师工作流。

@OliverBaumgart 开源了(7 次点赞、1 条回复、456 次浏览、9 次收藏)PocketDaemon,其 README 将其描述为一个实验性的 Android 原生 AI 手机智能体,使用 Flutter 加 Android/Kotlin 服务构建,具备本地记忆、定时任务、手机工具,以及可选的基于 Magisk 的特权安装路径。在信息流另一侧更偏安全的角落里,@tom_doerr 分享了(2 次点赞、132 次浏览)Pentest Copilot,其 README 将其描述为一个基于浏览器的 AI 渗透测试智能体,集成了 Burp、浏览器自动化、VPN 处理和后台子智能体并行。
讨论要点: 这里最有价值的质疑,来自金融讨论下的回复。在 @jerryjliu0 的贴文下面,实践者不断强调,真正的难点不是抽出一个字段,而是知道它何时悄悄出了错,以及在人工签字前把互相矛盾的文档对齐。安全方向又补了一层提醒:@Thionne_WTZ 借一篇 Hermes 深度解读发出警告,说假冒的“free Claude Code”仓库正在分发恶意软件,这也提醒人们,智能体式工具链同样正在被用于供应链校验。
与前日对比: 5 月 16 日已经通过仓库增长榜和交易栈把金融显示为热门垂直方向。5 月 17 日则补上了更扎实的工作流证据——文档管线、仪表盘、手机原生智能体和安全工具——让构建者组合看起来更广,也更偏运营层面。
2. 令人困扰的问题¶
运行框架开销依然昂贵、有状态,而且很容易被低估¶
最清晰、最严重的挫败感,是可靠智能体背后仍然捆着一大笔隐藏运营成本。@vipulgupta2048 展示了(12 次点赞、4 条回复、581 次浏览、6 次收藏),哪怕只是一个无关紧要的问候,一旦把缓存写入、工具 schema、CLAUDE.md、技能、记忆和启动调用都算进去,成本也会继承出大约 8 美分。@valentinmihov 透露(14 次点赞、5 条回复、947 次浏览、7 次收藏),他们团队的运行框架为了搭起来花掉了约 6 亿 token 和大约 3,000 美元,尽管他依然认为这比搭一套同等级基础设施更便宜。@shannholmberg 描述了(148 次点赞、14 条回复、12,007 次浏览、218 次收藏),一个专家智能体在可以安全部署之前,需要经历反复纠正的循环,而有回复提醒说,即便这些重复试跑,也可能把系统过拟合到干净的运行框架里。严重度:高。当前看得见的权宜方案,是尽量待在长生命周期会话中、把运行框架上下文维持得精简,并把智能体更像有状态服务而不是廉价函数调用来对待。值得构建,因为一线操作者已经在要求更好的成本核算、回归可见性和运行框架工程纪律。
文档密集型智能体在高风险环节仍然会失效¶
高风险文档工作流是少数几个会在回复里不断补上比原帖更严苛约束的场景。@jerryjliu0 说(89 次点赞、8 条回复、6,117 次浏览、128 次收藏),金融智能体需要严格的 OCR、评估检查和 HITL 审查,因为即便轻微的数字错误,往下游传递都可能是灾难。回复把失效模式讲得更尖锐:一条说抽取质量不等于可审计性,另一条说金融运营质量的真正标准,是能否安全地把人工审阅者从流程里移除,还有一条说跨文档对账比任何单文档解析都难。严重度:高。今天的权宜方案仍是增加人工复核、对账逻辑和显式审计界面,而不是全自动化。值得构建,因为这个痛点非常实际,实践者反复提起,而且这些工作流本身就足以支撑真实付费。
智能体商业化仍缺乏可信的结算和治理基础设施¶
最强的治理类挫败感,不在于发现,而在于智能体采取行动之后会发生什么。@sijlalhussain 认为(14 次点赞、2 条回复、327 次浏览、3 次收藏),智能体商业的信任,不取决于品牌话术,而取决于身份验证、人工监督、透明度、数据安全和可追责治理。在 @Unibase_AI 的市场贴文(20 次点赞、76 条回复、101 次引用、31,917 次浏览)下,最有实质内容的一条回复说,要让实际工作真正结算,组合式技能调用仍然需要托管结算、交付物哈希和评估者结算。严重度:高。当前的权宜方案仍是人工批准、人工覆盖,或额外的链下协调。值得构建,因为发布活动已经跑在信任和结算层前面。
智能体供应链已经嘈杂到开发者开始公开互相示警¶
另一个规模较小但非常具体的挫败点是,围绕智能体的生态里现在已经混入了明显的安全陷阱。@Thionne_WTZ 警告(11 次点赞、4 条回复、648 次浏览),一个假的“free Claude Code”仓库是当前恶意软件活动的一部分,并称 GitHub 上看得到的源码只是诱饵,真正的风险藏在 ZIP 安装器里。链接的 rosie 安全文档 用更一般的方式描述了同类问题:外部 Markdown 和技能内容可能夹带恶意指令、标签改写或不可见字符注入,因此锁定文件、注释剥离和审计日志都被当作必要防线。严重度:中。当前的权宜方案是优先走官方渠道、固定引用版本,并显式审查第三方智能体内容。值得构建,因为这个警告已经是运营层面的,不再只是理论风险。
3. 人们期望的功能¶
不会劣化的持久程序性记忆¶
最明确的实际需求,不是泛泛的记忆,而是那些能在反复复用中保留下来、又不会变成杂物堆的过程记忆。@akshay_pachaar 把(75 次点赞、13 条回复、6,471 次浏览、79 次收藏)Hermes 技能定位为智能体应该存放“问题是怎么解决的那套确切步骤”的地方,同时也承认,必须有一个 Curator,不然技能库会迅速塌成重叠内容和死重。@tom_doerr 分享了(12 次点赞、3 条回复、1,584 次浏览、15 次收藏)miniclawd,其 README 又把持久记忆、cron 调度和子智能体并到了同一张图里。机会:直接。人们想要的不只是回忆能力,而是可复用、可整理、会累积却不会变成维护负担的运营记忆。
面向受监管工作的可审计文档上下文智能体¶
金融讨论串把这种未满足需求说得异常直接。@jerryjliu0 描述(89 次点赞、8 条回复、6,117 次浏览、128 次收藏)当前栈是 OCR、评估和 HITL 审查,而回复却不断强调,真正的阻塞点是静默抽取错误和跨文档对账。这读起来与其说是在要更聪明的模型,不如说是在要一种系统:它能证明自己抽取了什么、对齐互相矛盾的信息,并且向审阅者准确展示证据来自哪里。机会:直接。这个需求是运营层面的、痛感明确的,而今天的文档管线仍只解决了一部分。
面向智能体商业化的结算、身份与人工接管层¶
商业类讨论串不断绕回同一个缺失的底层:智能体是谁、谁能叫停它、它做完的工作又该如何验证。@sijlalhussain 说(14 次点赞、2 条回复、327 次浏览、3 次收藏),信任取决于身份验证、人工监督、透明度、数据安全和可追责治理。在 @Unibase_AI 的贴文(20 次点赞、76 条回复、101 次引用、31,917 次浏览)下,一条回复又把托管结算、交付物哈希和评估者结算补进了同一张清单。机会:直接且竞争激烈。需求很具体,但多个市场已经在信任层尚未定型之前,自上而下地抢着填这个空白。
具备现实权限的私有、常驻型个人智能体¶
一个较安静但真实存在的需求,是那些生活在个人设备上、能按计划行动而不是只待在浏览器标签页里的智能体。@OliverBaumgart 发布了(7 次点赞、1 条回复、456 次浏览、9 次收藏)PocketDaemon,其 README 将其描述为一个具备通话、本地记忆、调度和手机工具的已 root Android 手机智能体。@tom_doerr 强调了 miniclawd 在桌面侧的持久记忆和调度能力。机会:直接但偏小众。这个需求对希望拥有本地控制权的高级用户很实际,但现有方案仍然需要技术部署,并要求用户明确接受设备级权限带来的信任前提。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Learn Harness Engineering | 课程 / 参考资料 | (+) | 面向编程智能体的环境设计、状态管理、验证和可观测性的公开课程体系 | 仍只是教学材料;运营者还得自己把它转化进各自的栈里 |
| Hermes Agent | 智能体运行时 | (+/-) | 自进化技能、持久化智能体工作流、Grok 订阅访问,以及专家智能体部署模式 | 用户仍反馈长会话中的记忆不一致,以及技能蔓延后的清理工作 |
| Claude Code + harness stack | 编程智能体运行时 | (+/-) | 靠技能、MCP、钩子、子智能体和项目上下文提供很强的可扩展性 | 隐性的缓存 / 启动成本可能压过小交互本身 |
| Official skill repos (Google skills, Anthropic skills) | 技能库 | (+) | 一条命令安装打包能力,不必再为云 / 服务工作流手写上下文 | 公开热情领先于清晰的使用数据;技能仍需要策展和版本控制 |
| softaworks/agent-toolkit | 技能市场 / 库 | (+) | GitHub 1,844 星,提供覆盖日常编码工作流的广泛可安装技能、智能体和命令目录 | 又多了一层团队必须审核和维护的第三方内容 |
| miniclawd | 个人智能体运行时 | (+) | 在轻量 TypeScript + Bun 栈中提供多 LLM 支持、内置工具、Markdown 技能、持久记忆、cron 调度和子智能体 | 项目仍小,公开的一线运营验证还很有限 |
| PocketDaemon | 移动端 / 手机智能体 | (+/-) | 在 Android 原生栈里提供电话、实时语音 / 聊天、本地记忆、日程和设备工具 | 已 root 的 Android + Magisk 要求,使它更像研究级项目而非大众产品 |
| TencentDB Agent Memory | 记忆层 | (+) | 分层本地记忆、token 降低,以及默认零外部 API 依赖的显式召回 / 下钻路径 | 插件配置和分层存储增加了运营复杂度 |
| TradingAgents | 金融框架 | (+/-) | 开源多智能体交易栈,把分析师、情绪、组合和执行角色整合在一起 | 回复仍在质疑重度依赖情绪信号的群体系统是否能稳定胜过更简单的方案 |
| Pentest Copilot | 安全智能体 | (+/-) | 结合 Kali、Burp、浏览器自动化、VPN 处理和后台子智能体的浏览器式渗透测试 | 只能用于授权测试,而且操作起来比主流编程智能体更重 |
整体来看,这一天大家对那些把能力外置到技能、钩子、记忆和显式运行时中的工具更偏正面,而不是把行为埋进提示词。当天最主导的权宜方案模式是:用可安装的技能包替代手写上下文,用定时或持久化智能体替代无状态聊天,用可检查、可迭代的运行框架替代模糊提示。竞争焦点正从“最好的模型”转向“最好的外围系统”——记忆管理更干净、运行框架税更低、第三方技能接入更安全,操作者界面的设计取向也更鲜明。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| 消费者支出追踪智能体 | @FundamentEdge | 围绕消费者消费能力输入搭建仪表盘,并允许分析师调整校准参数与关联关系 | 减轻投资工作中维护宏观消费者支出框架的人工负担 | 未披露;仪表盘 + 宏观与另类数据管线 | Alpha | 推文 |
| miniclawd | FoundDream | 轻量个人智能体,支持多 LLM、工具、技能、持久记忆、cron 任务和子智能体 | 给高级用户一个可持久运行、可调度的个人智能体,而不是一个被动响应的聊天窗口 | TypeScript、Bun、Markdown 技能、Telegram、Feishu | Beta | 仓库, 推文 |
| PocketDaemon | @OliverBaumgart | 把一部已 root 的 Android 手机变成一个语音 / 聊天智能体,可接电话、调用手机工具、保留本地记忆并安排任务 | 把智能体行为带到带有本地状态和现实手机权限的个人设备上 | Flutter、Android/Kotlin 服务、Magisk、Gemini/xAI 提供商 | Alpha | 仓库, 推文 |
| Pentest Copilot | Bugbase Security | 基于浏览器的 AI 渗透测试系统,可连接 Kali 主机、运行工具、检查结果,并与子智能体迭代协作 | 在浏览器、代理和 shell 界面之间自动化重复性的渗透测试工作流 | JavaScript、Docker、Kali、Burp Suite、浏览器自动化、VPN 支持 | Beta | 仓库, 推文 |
消费者支出追踪智能体之所以突出,是因为截图展示的是一个真实的分析师操作界面,而不是概念草图。它也是 5 月 17 日常见构建模式里最清晰的例子之一:拿一个现成的专家框架,接入更新的数据源,把更新循环自动化,而不是从零发明一个新工作流。
miniclawd 和 PocketDaemon 从两个端点指向同一个更大的方向。miniclawd 把持久记忆、调度和子智能体打包进一个轻量的桌面 / 服务器式助手里,而 PocketDaemon 则把同样的持久化思路推进到手机上,结合电话、笔记、日程和本地设备工具。反复出现的核心诉求是连续性:构建者想要的是会记住、能定时醒来,并且在受限环境里行动的智能体。
Pentest Copilot 在安全领域呈现了同样的模式。它的 README 强调自治命令执行、Burp 集成、浏览器自动化和后台任务并行,这让它更像是围绕专业环境封装的一台工作流引擎,而不像一个给黑客用的聊天机器人。
6. 新动态与亮点¶
GitHub 将“智能体监督者”角色正式化¶
@_vmlops 发文称(33 次点赞、3 条回复、1,810 次浏览、28 次收藏),GitHub 已推出处于 beta 阶段的 GitHub Certified Agentic AI Developer 认证。附图是核心证据:它直接写出了这项认证的名称,并把重点放在软件生命周期中如何运营和治理智能体,而不是仅仅学会使用一个助手,因此这是一个劳动力市场与职业化信号。

斯坦福论文质疑“默认采用多智能体”的思路¶
@rohanpaul_ai 总结了(4 次点赞、838 次浏览、6 次收藏)一篇斯坦福论文的观点:在思考 token 预算相同的前提下,单个强模型在多跳推理上通常能追平甚至击败多智能体系统。它之所以重要,是因为它给当天流行的编排热泼了一盆很有价值的冷水:多加几个智能体并不会自动变好,一些肉眼可见的增益也可能只是测试时算力增益的伪装。

Codex 可能正在吸收实时语音和后台讲解¶
@DevAdventur3s 报告称(99 次点赞、12 条回复、7,010 次浏览、25 次收藏),OpenAI 看起来正在把实时语音接进 Codex:由后台智能体处理编码工作,界面则负责讲解进度。第二张截图是关键的公开证据,因为它展示的不是猜测,而是 Rust 代码路径中的 WebRTC、gpt-realtime-1.5、后台智能体交接以及进度钩子。

7. 机会在哪里¶
[+++] 运行框架成本与回归核算 —— 第 1 节和第 2 节从不同侧面指向同一个缺口:人们现在已经能讲清运行框架怎么搭,却仍然难以给它核算成本、检查状态并加以控制。@vipulgupta2048 把“为什么打个 hi 也要花钱”拆成了缓存与启动过程的明细,而 @valentinmihov 公布了整套栈的成本披露,@shannholmberg 则描述了部署前的迭代负担。机会很强,因为这种痛点反复出现、成本高,而且落在已经存在的一线操作行为上,不是未来想象。
[++] 面向受监管运营的可审计文档智能体 —— 金融方向的构建者已经在尝试自动化 KYC、贷款和研究工作流,但围绕 @jerryjliu0 的回复不断强调,真正阻碍上线的是静默抽取错误和对账失败。机会中强,因为买方已经可见,而且需求足够窄,适合直接构建:证据可追溯性、面向审阅者的审计界面,以及跨文档矛盾处理。
[++] 技能与记忆的生命周期管理 —— @akshay_pachaar 想要会累积的程序性记忆;回复想要它不要漂移、不要堆满;miniclawd 和官方技能仓库则从另一个角度展示了相同的打包趋势。机会中等,因为生态显然正在转向可安装技能和持久化智能体,但团队仍然需要更好的策展、过期机制、测试和跨运行时可移植性。
[+] 智能体生态的信任与供应链保障 —— 智能体市场的出货速度快于结算逻辑,而恶意“free Claude Code”克隆的安全警告已经出现。这让身份、托管结算、可审计性、带签名的技能来源证明,以及安全接入第三方内容,成为一个正在浮现但很重要的机会,尤其是对那些在公开市场或共享技能注册表里运作的团队来说。
8. 要点总结¶
- 运行框架工程已经不再是这个话题里的小众研究词;现在既有人系统教学,也有人把它落进生产并开始核算成本。 最强的帖子是公开课程、生产配方和一手成本拆解,而不是抽象的模型吹捧。 (来源)
- 正在胜出的控制面,正从提示词文本转向技能、记忆、钩子和 MCP 风格集成。 Hermes 的技能累积、厂商官方技能仓库和 Claude 架构图都指向同一个方向。 (来源)
- 金融是最清晰的现实需求集中区之一,但前提是智能体必须证明自己的工作。 金融讨论串里充满了对 OCR 错误、静默坏抽取和对账失败的警告,可见可审计性是产品本体的一部分,不是最后打磨。 (来源)
- 持久化智能体正在进入更具体的载体:仪表盘、手机和安全工具。 当天的构建案例包括一个消费者支出仪表盘、一个已 root 的 Android 手机智能体,以及一个基于浏览器的渗透测试系统。 (来源)
- 这个领域仍在公开纠正自己的过度乐观。 一篇斯坦福论文质疑了“默认多智能体”的思路,而市场与安全讨论串也在不断提醒读者:更多智能体、更多技能或更多集成,并不会消除治理与信任需求。 (来源)