OpenAI 在 DevDay 宣布 ChatGPT 周活跃用户突破 12 亿，约相当于全球人口的 15%。这么多人和越来越多的 AI 智能体同时发起请求，每次聊天、API 调用和模型调用都得先验证身份和权限，传统集中式身份系统在高并发下容易成为瓶颈。OpenAI 采用 Ory 的解耦认证引擎和 OAuth2/OIDC 基础设施，让令牌校验在边缘以无状态方式完成，减少反复回查中心数据库。文章还比较了自托管可组合 IAM 与传统身份 SaaS 在数据主权、成本和扩展方式上的差异，并提到让智能体先“观察模式”运行、再收紧权限的思路。对读者的价值是：了解面向超大规模和智能体负载设计身份鉴权时的关键取舍。
文中可用工具
- Ory提供解耦的认证引擎和 OAuth2/OIDC 身份基础设施，供 OpenAI 这类超大规模场景使用
- Ory Kratos处理身份生命周期、凭证哈希和会话管理的微服务
- Ory Hydra高性能 OAuth2/OIDC 服务器，负责签发访问令牌和管理授权流程
- Ory Keto基于 Google Zanzibar 模型的细粒度权限控制引擎，评估关系元组
- ChatGPTOpenAI 的聊天产品，文中称其周活跃用户已超 12 亿
- Codex原文仅提及名称，未说明具体用途
- CockroachDB分布式 SQL 数据库，用于跨区域复制身份验证状态
- Spanner原文仅提及名称，未说明具体用途
- Postgres原文仅提及名称，未说明具体用途
- Auth0文中作为传统多租户身份 SaaS 的例子出现
- Okta文中作为传统多租户身份 SaaS 的例子出现
- Ping Identity文中作为传统多租户身份 SaaS 的例子出现
展开详情收起详情：从人类点击到智能体速度：OpenAI 12 亿用户规模对你的鉴权意味着什么⌄
The New Stack
原文发布：2026-10-28 20:00收录：2026-10-29
这篇文章讲的是：当负责处理退款的 AI Agent 中途崩溃时，如何让接替它的新 Agent 安全接手，而不会重复退款。原来问题在于，Agent 会自己推理、临时决定，崩溃后新 Agent 可能重新想一套方案，甚至再退一次款，导致用户被退两次钱。作者的做法是：在发起退款前，先把这笔操作的金额、授权、幂等键和状态写进数据库（相当于先立一张可查的“操作底账”），新 Agent 只能继承这张底账，不能自己改写；支付接口前还有一层校验，只放行记录里已授权的操作。这样即使崩溃，也能靠同一个幂等键和操作编号查清到底发生了什么，避免重复退款。对读者的用处是：如果你在生产环境跑 Agent 处理支付、订单等有副作用的操作，可以用“持久操作记录+幂等键+边界校验”的思路提升可靠性。文中提到的 LangGraph、Temporal 能恢复执行，但不能判断外部是否已成功；Langfuse 和 ClickStack 可用于追溯，但都只是辅助证据，最终以支付方记录为准。
文中可用工具
- ClickHouse Managed Postgres存放业务数据和权威操作记录
- ClickStack查询应用遥测和日志
- Langfuse查看 Agent 调用链和工具调用记录
- LangGraph持久化执行进度并在失败后恢复
- Temporal持久化执行进度并在失败后恢复
- Langfuse MCP server让 Agent 按操作 ID 查询此前的调用链
- ClickStack MCP server让 Agent 检索同一时间窗口内的服务事件
展开详情收起详情：AI Agent 需要可替换——同时不丢失工作成果⌄
The New Stack
原文发布：2026-10-28 21:00收录：2026-10-29
文章用一个虚构例子说事：云平台上有一个叫 research-agent-2 的账号，它的访问密钥是 14 个月前创建的，最后一次使用是 11 个月前，但至今仍然有效。问题出在：人离职会触发账号回收流程，但一个干完活的 AI 助手（agent）往往只是关掉页面就走，没人回头清理它的权限；而 AWS IAM 的访问密钥不会自动过期，于是这把旧钥匙一直能开门。文章引用 OWASP 2025 年非人类身份风险榜单，把“下线条目没处理好”排在第一位，并提到 2026 年 9 月 GreyNoise 记录的一次攻击：从零到在真实目标上实现远程代码执行不到 4 小时，26 秒内攻陷至少 11 家机构，说明拖慢清理很危险。解决办法分三步：用 CloudQuery 把 AWS 凭证报告同步进数据库，再用给出的 SQL 查询找出“创建超过 90 天且 90 天以上没用过”的有效密钥，然后由指定负责人复核，配合策略和定时任务处理。注意 90 天只是复查门槛，不是判死刑；查询不包含 root 账号密钥，那需要单独紧急审计。文章提供的是自查方法和查询语句，属于已给出的操作指导，不是新发布的工具。
文中可用工具
- CloudQuery把 AWS IAM 凭证报告同步到数据库，方便用 SQL 查询长期未用的密钥
- AWS IAM管理用户访问密钥，其密钥不会自动过期
- ClickHouseCloudQuery Platform 使用的查询数据库方言
- PostgreSQL另一种可运行文中查询语句的数据库
展开详情收起详情：Agent 早已消失，它的访问密钥却还活着，会发生什么？⌄
The New Stack
原文发布：2026-10-28 22:00收录：2026-10-29
Legora 是一家做法律 AI 的公司，它利用 OpenAI 的模型、ChatGPT 和 Codex 来加速法律工作流程。原来律师处理合同分析等工作费时费力，现在可以由 AI 帮忙做合同分析，把律师从重复劳动里解放出来，让他们专注更有价值的工作。不过材料只说明了用途，没有交代具体效果数据、可用范围或发布时间。
文中可用工具
- OpenAI 模型为法律工作流提供 AI 能力，原文未说明具体模型名称
- ChatGPT用于加速法律工作流程
- Codex用于加速法律工作流程
展开详情收起详情：Legora 正在打造法律工作的智能体操作系统⌄
OpenAI News
原文发布：2026-10-28 17:30收录：2026-10-29
LangChain 把自家开源工具 OpenWiki（一个把原始文档编译成带引用维基页面的命令行工具）当作 Agent 的长期记忆层，并额外用一张"证据图谱"把维基里的结论和它背后的原文段落连起来。原来的问题是：Agent 每次回答跨文档的问题都要临时检索、拼凑，既慢又容易答错。这次的做法是提前把 111 份模拟保险文档编译成约原体积十分之一的维基，再让 Agent 顺着图谱找到支撑证据。结果显示，涉及多来源关联的问题准确率比只用关键词搜索高约 5 倍；加上证据图谱后准确率再提升 27%，引用一致性翻倍，每个正确答案的成本降低 58%。不过对于简单的单段查找，带记忆反而更慢、准确率没提升，所以这套方案更适合需要反复跨来源推理的场景。该工具已开源，文中未说明证据图谱是否单独开放。
文中可用工具
- OpenWiki开源命令行工具，把原始文档编译成带引用、可随源文档变化自我更新的维基页面，用作 Agent 的持久记忆层
- Deep AgentsOpenWiki 构建所基于的框架，原文未详细说明其用途
- 证据图谱把维基中的结论与支撑原文段落、相关文档用边连接起来，供 Agent 追溯引用来源
展开详情收起详情：如何用 OpenWiki 和证据图谱构建有据可依的 Agent 记忆⌄
LangChain Blog
原文发布：2026-10-29 01:28收录：2026-10-29
LangChain 团队介绍了如何用“定时任务”（cron，就是让程序按固定时间自动跑一次的机制，类似手机闹钟）来构建主动式 Agent（能自己做事、不用人每次发指令的 AI 助手）。过去这类 Agent 大多只靠简单定时任务，现在他们发现定时任务还能解锁记忆整理、主动提醒、信息筛选、定时跟进和多 Agent 调度等能力。做法上需要两部分：一个方便的定时任务服务器，以及让 Agent 自己能创建和修改提醒的接口。托管深度智能体（MDA）内置了这样的服务器，支持写死在代码里的固定任务，也支持用户临时让 Agent 自己排期。官方称 LangSmith 上超过 70% 的托管深度智能体运行来自定时触发而非人工发消息。文中示例代码可用于参考，但未说明该功能的具体开放状态和限制。
文中可用工具
- Managed Deep Agents托管运行的深度智能体平台，内置定时任务服务器，可按计划触发 Agent 运行
- Schedules SDK用于定义和管理定时任务的开发工具包，支持固定与动态排期
- LangSmith Deployments托管部署环境，文中说明托管深度智能体运行于此
- LangChain提供 tool 装饰器等工具封装能力，用于把排期功能做成 Agent 可调用的工具
- Muse原文仅提及名称，未说明具体用途
- Instinct原文仅提及名称，未说明具体用途
- Dots原文仅提及名称，未说明具体用途
- Claude Duet原文仅提及名称，未说明具体用途
- Hone文中作为有明确目标的专用主动式 Agent 举例，会按小时检查并推进目标
展开详情收起详情：如何在托管深度智能体中用 Schedules SDK 构建主动式常驻 Agent⌄
LangChain Blog
原文发布：2026-10-29 01:28收录：2026-10-29
LangChain 团队写了一篇博客，讲怎么让 AI 智能体（能自己调用工具干活的程序）更可靠。原来只靠一个好模型不够，还得给它配一套适合具体任务的“外挂”结构。他们把智能体拆成四层循环：最里面是模型反复调用工具干活；外面加一层检查，输出不合格就打回重做；再外面让智能体被事件自动触发，比如收到消息或定时任务；最外面一层分析每次运行的记录，自动改进提示词和工具配置。文章还强调人工审核该在哪些环节介入敏感操作，并用他们自家的 LangChain、LangSmith 等工具演示每一层怎么搭。目前是概念说明和产品能力介绍，不是新发布。
文中可用工具
- LangChain搭建智能体循环和中间件的开源框架
- create_agent快速创建一个模型调用工具的智能体循环
- RubricMiddleware按评分标准检查智能体输出并反馈重做
- LangSmith记录和分析智能体运行轨迹的平台
- LangSmith Deployment提供定时任务和 webhook 等触发基础设施
- Engine分析运行轨迹、发现问题的智能体
- Fleet无需写代码搭建智能体，支持频道和定时触发
- openclaw原文仅提及其“心跳”定时触发用法，未说明具体用途
展开详情收起详情：循环工程的艺术⌄
LangChain Blog
原文发布：2026-10-29 21:20收录：2026-10-29