Datadog 的工程师用自家产品 Insights 来观察和优化他们自己的 AI agent。Insights 会分析 agent 的运行记录，找出它在哪些地方花了过多 token、工具调用失败或任务没完成，并解释原因、估算影响、给出有依据的修复建议。例如它发现搜索工具一次返回太多内容，导致后续请求被重复计费；还发现请求顺序不对，使提示缓存无法复用，估算每月可省约 2734 美元。工程师随后把建议交给编程 agent 改代码，并通过重放原任务验证修复后 token 是否更少、回答是否仍然正确。这是 Datadog 的自用案例，节省数字为估算、尚未实测。
文中可用工具
- Insights分析 agent 运行记录，找出成本与可靠性问题并给出修复建议
- Agent ObservabilityDatadog 用于观测 AI agent 的产品，Insights 位于其中
- search_llmobs_spans在已记录的 trace 中搜索证据的工具
- update_insight用于更新已有 insight 的工具
- Fix with Bits把 insight 的证据与建议交给编程 agent 修改代码
展开详情收起详情：我们如何用 Insights 改进 Insights 背后的 agent⌄
Datadog Blog
原文发布：2026-10-30 08:00收录：2026-10-31
Kubernetes 社区在 10 月 27 日宣布成立一个专门的工作组，要为「工作负载在 Kubernetes 上运行时的行为」制定统一标准。此前虽有测试能判断一个集群能不能跑 AI/机器学习任务，但对于具体工作负载本身没有类似标准，团队只能靠变通办法、手动摸索，或者盯着节点被清空、权限报错这类迹象来排查问题。新工作组希望补上这块空白，让不同工作负载在集群里的运行表现有一致、可检验的规范。对跑 AI 工作负载的团队来说，这意味着未来判断平台是否适合自己的任务会更有依据；不过目前只是宣布成立并征集社区意见，标准尚未发布。同期还有：TNS 与 HPE 合作发布一本关于在 Kubernetes 上运行 AI 工作负载的电子书，可立即下载；OpenTelemetry 转换语言 OTTL 达到 v1，对 traces、metrics、logs 稳定，包含在 Collector Contrib v0.164.0 及之后版本，并承诺语法和标准函数保持向后兼容。另有 AWS 架构师预告将在 KubeCon 展示用 agent 流水线实时分析工作负载并在 GPU 上共置多个模型的方案，属于演示预告，原文未说明可用时间。
文中可用工具
- Kubernetes容器编排平台，文章讨论其上新成立的工作负载一致性工作组
- Kubernetes AI Conformance已有测试，用于判断集群能否运行 AI 或机器学习工作负载
- OpenTelemetry Transformation Language (OTTL)OpenTelemetry 的配置语言，可在收集器层修改、过滤和丰富遥测数据
- Collector ContribOpenTelemetry 收集器贡献版，v0.164.0 起包含 OTTL v1
- VPC Flow LogsGoogle Kubernetes Engine 内置功能，记录 IP、端口和协议之间的连接，帮助排查临时 Pod 的问题
展开详情收起详情：Kubernetes 成立工作负载一致性工作组，为何对 AI 团队意义重大⌄
The New Stack
原文发布：2026-10-31 01:29收录：2026-10-31
DoorDash 优化了杂货复购流程：过去用户要等约 16 秒才能重新下单，现在缩短到约 2 秒。做法是提前用批量 LLM 推理算出用户常买的东西，再用确定性的规则校验，而不是每次临时让模型现算；同时实时核对商品目录，保证选中的货还在售，并把清单做成可编辑界面，用户不改就不必再调用模型。DoorDash 称购物清单浏览量翻倍，该流程下单率提升约 34%。这些数字来自公司自述，文中未说明上线范围、统计口径和具体模型。
展开详情收起详情：DoorDash 借助 AI Agent 将杂货复购延迟从 16 秒降至 2 秒⌄
InfoQ Architecture & Design
原文发布：2026-10-30 21:31收录：2026-10-31
Datadog 的几位工程师建议，AI Agent 的工作负载应优先考虑无服务器（按请求分配算力、空闲缩到零）而不是常开服务器。他们分析了超过 3.5 万次生产环境编程 Agent 会话，发现中位数会话只有 20% 的时间在真正调用模型或工具，其余时间都在等待，但沙箱资源一直占着，常开算力等于为闲置时间付费。做法是先给工作负载建一份「执行画像」，记录峰值并发、单次运行的实际计算时长与总耗时之比等，再据此判断用按需算力还是专用节点；长任务可以拆成可恢复的无服务器工作流，等待时释放算力、下一步就绪再继续。读者可以据此避免过早购买常开算力，并用上线后的真实数据再决定是否迁移，文中还提到可用 Datadog 的 Agent 可观测性、APM 和无服务器监控来测量这些指标。
文中可用工具
- Datadog Agent Observability观测 AI Agent 的运行，测量每次运行的总耗时和各步骤时长
- Datadog APM通过链路追踪查看模型、工具和应用层面的耗时
- Datadog Serverless Monitoring测量无服务器组件的执行时长、调用量、并发和 CPU 内存使用
- AWS Lambda文中举例的无服务器计算服务，增强指标可报告 CPU 利用率和 CPU 时间
展开详情收起详情：AI Agent 默认先用无服务器，让生产数据决定何时迁移⌄
Datadog Blog
原文发布：2026-10-29 08:00收录：2026-10-30
OpenAI 此前报告了一种“自我复制提示注入”：攻击者把隐藏指令藏在 AI 智能体读取的内容里，诱导智能体照做，并把这些指令复制进邮件、文件或消息中，从而感染其他智能体和后续会话，像电脑蠕虫一样扩散。这次 Datadog 把 OpenAI 报告中的两个例子改造成针对测试智能体的模拟攻击，并用其安全产品 Datadog AI Guard 检查智能体读到的内容和发起的工具调用。结果 AI Guard 在看邮件或 CSV 时，就标记了被植入的内容不安全；当测试智能体把注入指令复制进回复或技能文件时，AI Guard 也判定这些操作不安全。需要注意的是，这是模拟环境中的演示，不是正式发布的新功能，也不能说明真实的拦截成功率；文章的重点是展示如何排查智能体最终回复里看不出来的可疑行为。
文中可用工具
- Datadog AI Guard评估 AI 智能体的输入、输出和工具调用，标记提示注入等不安全行为
- GPT-5.4 mini测试智能体所用的 OpenAI 模型
展开详情收起详情：检测 AI 智能体是否复制自我复制的提示注入⌄
Datadog Blog
原文发布：2026-10-29 08:00收录：2026-10-30
Anthropic 推出后台助理 Claude Duet，会自动查看你已连接的应用，主动判断哪些事需要你处理。问题是“什么算紧急”本身很主观，而且它由 Claude Opus 5.5 驱动，可能误读对话或判断错优先级。为此 Anthropic 用员工日常工作校准了一套内部评分器，离线检查它排优先级的对错，同时另设一个独立于执行模型之外的自动检查器，看每个动作是否符合你的意图，以降低网页里藏指令骗它的风险。目前 Duet 只对美国 Pro 和 Max 订阅者开放且有等待名单；后台检查每几小时一次并计入用量额度，官方未说明评分的准确率，也还不能让你实时查看或接管它在云端浏览器里的每一步。
文中可用工具
- Claude Duet自动监控已连接应用并在后台处理任务的 AI 助理
- Claude Opus 5.5驱动 Claude Duet 的模型
- Claude Code其自动模式分类器被扩展用于 Duet 的独立动作检查
展开详情收起详情：“紧迫性本质上是主观判断”：Anthropic 向 TNS 介绍如何评估 Claude Duet⌄
The New Stack
原文发布：2026-10-29 19:00收录：2026-10-30
很多平台团队每年都会自己写 Kubernetes 控制器，用来自动创建 Deployment、Service、ConfigMap 之类的一堆对象，并在它们之间传递字段。Kubernetes 本身已经提供了 CRD、控制器、Server-side apply、CEL、OpenAPI 这些零件，却没有说明“几个资源算一个整体、谁先谁后、某个值要从另一个资源的状态里取”的说明书，所以 Helm、Argo CD、Crossplane、Operator 等每个工具都各自补这一块，成千上万的组织在重复造同一个轮子。kro（Kube Resource Orchestrator）把这段“接线”写成数据，叫 ResourceGraphDefinition：由 CEL 表达式里的引用来推断依赖顺序，并在实例创建前做类型检查，一个控制器就能解释所有定义，应用团队照样用 kubectl、RBAC 和 GitOps。它还在 2025 年 9 月进入 Kubernetes SIG Cloud Provider，定位成别人可以搭建的底层原语；0.10 版本新增的 Graph 只保留组合部分、不需要 CRD 和实例，适合“给打了标签的 Service 自动生成 Ingress”这类一次性场景。读者可以少写一堆粘合控制器，但要意识到 API 一旦发布就是承诺，成本从“写”变成“长期维护”。
文中可用工具
- Kubernetes容器编排平台，提供 CRD、控制器、RBAC 等基础能力
- Kubebuilder帮助开发者快速搭建 Kubernetes 控制器的框架
- Helm在渲染阶段管理一组资源，Helm 4 增加了服务端应用和等待资源状态
- Argo CDGitOps 工具，用同步波次、钩子和健康检查补足清单里缺失的顺序与就绪信息
- Crossplane用组合和函数管理资源，v2 可直接组合原生 Kubernetes 资源
- kro（Kube Resource Orchestrator）把资源接线写成数据，由单个控制器解释，0.10 的 Graph 用于无需对外 API 的场景
- CEL在集群内求值的表达式语言，kro 用它表达资源间引用并推断依赖顺序
- OpenAPI为字段提供类型定义，kro 在实例创建前据此做类型检查
- Server-side apply跟踪每个字段由谁拥有，避免多方写入冲突
展开详情收起详情：Kubernetes 平台为何反复重建本可共享的编排层⌄
The New Stack
原文发布：2026-10-29 21:00收录：2026-10-30
AWS 的开发者倡导者 James Ward 提出，很多 MCP 服务器目前只是被动地返回数据，就像一个只负责查数据的接口。他建议服务器在返回数据时顺便告诉 Agent 刚做了什么、接下来可以做什么、去哪里找更多信息，相当于让服务器成为对话中的另一个参与者。他还指出 MCP 默认无法追踪调用链路，AWS 的做法是给工具加会话 ID 参数，让多次调用串成完整旅程，再加一个参数记录用户目标，方便团队复现问题、做评测并改进工具。对使用 MCP 的团队来说，这意味着要同时观察人和 Agent 协作的路径，检验工具改动是否真的帮用户完成任务。文中提到 AWS 已于 5 月向所有人开放其 MCP Server，并在 9 月加入 Lambda 诊断功能；这些做法本身并不新奇，重点在于能否持续观测和衡量。
文中可用工具
- MCP ServerAWS 提供的 MCP 服务器，现已向所有人开放，并加入了 Lambda 诊断功能
- Lambda diagnostics用于 Lambda 的诊断能力，帮助排查问题
- CLIAWS 提供的命令行工具，可在不同 AWS 用户配置之间切换
- skills原文未说明具体用途
展开详情收起详情：为什么 MCP 服务器应当告诉 Agent 下一步做什么⌄
The New Stack
原文发布：2026-10-29 23:55收录：2026-10-30
微软把 GitHub Copilot 背后的 Agent 调度框架通过 Microsoft Foundry 开放给外部开发者，作为托管服务提供。它自带沙箱、可复用的技能包、MCP 集成和对子 Agent 的支持，开发者只需选模型、写指令和配工具，运行环境由微软负责。目前是公开预览，到 2026 年 12 月 1 日前免费使用，之后按 CPU 和内存计费，模型推理等费用另算。好处是搭建 Agent 省事，但限制也明显：创建时选定的 harness 之后不能更改，CPU、内存和空闲时长由微软控制，也不能自带模型，更适合愿意接受这套约束的团队。
文中可用工具
- Microsoft Foundry微软的托管服务平台，用来构建和部署 Agent
- Foundry Agent Service提供 Copilot harness 的托管 Agent 服务
- GitHub Copilot微软的 AI 编程助手，也使用同一套 harness
- Copilot Studio微软用于构建 Copilot 产品的工具，同样基于该 harness
- VS Code代码编辑器，支持该 harness
- Azure Developer CLI用来部署和调用 Agent 的命令行工具
- MCP工具集成协议，接入时需要认证和审批
- azure.yaml配置文件，定义模型部署、工具、指令和 harness
展开详情收起详情：微软新 Copilot harness 让 Agent 搭建变简单，但想换就难了⌄
The New Stack
原文发布：2026-10-30 04:54收录：2026-10-30
LangSmith 的 Managed Deep Agents 现在能替你的 Agent 运行浏览器，让 Agent 像人一样点击、滚动和填表，去做那些没有 API 可用的网页操作，比如订机票或提交理赔。原来 Agent 只能抓网页源码，Java渲染出来的内容和按钮它都碰不到。这次提供了几种配套工具，还能在需要登录时把浏览器交给你本人操作，登录状态可以沿用。对读者来说，以后让 Agent 代办网页事务会更顺手，也不必把密码交给模型。
文中可用工具
- Managed Deep Agents在 LangSmith 里构建和部署 Agent，无需自己运维基础设施
- LangSmith运行 Agent 的托管平台，也用于查看和调试运行记录
- browser_snapshot读取页面结构并给可交互元素标上编号
- browser_run在页面上执行点击、填写等操作或一段脚本
- browser_screenshot截取渲染后的页面画面
- browser_handoff把浏览器交给真人操作，完成后再交还 Agent
- StagehandBrowserbase 开源的浏览器 Agent 开发 SDK，这些工具基于它构建
- WebVoyager用于测试浏览器 Agent 在真实网站上完成日常任务的基准
- Open SWE用浏览器做端到端测试的编程 Agent
展开详情收起详情：托管式深度 Agent 中的浏览器使用⌄
LangChain Blog
原文发布：2026-10-30 00:45收录：2026-10-30
Managed Deep Agents 发布 v0.10 版本。以前智能体只能处理有 API 的网站，遇到需要登录或点击的页面就卡住。新版本内置浏览器，能像人一样操作没有 API 的网站，遇到登录时把浏览器窗口交给你输入密码，模型看不到你的凭证；同时新增异步子代理，长任务放到后台跑，主智能体继续和你对话，结果完成后自动回到对话里。此外回复会回到发起请求的 Slack 线程，线程里还有停止按钮。
文中可用工具
- Managed Deep Agents管理和运行智能体的平台，本版本新增浏览器使用和异步子代理
- browser_handoff把远程浏览器窗口交给用户登录，避免密码进入模型消息和追踪记录
- LangSmith sandbox运行浏览器和子代理的沙箱环境
- Studio智能体渠道之一，可展示浏览器交接链接并恢复运行
- Slack对话渠道，回复回到原线程，并提供停止运行按钮
- define_browser在项目根目录声明浏览器及作用域的配置函数
- define_deep_agent定义深度智能体及其子代理的配置函数
展开详情收起详情：Managed Deep Agents v0.10：浏览器使用与异步子代理⌄
LangChain Blog
原文发布：2026-10-31 00:49收录：2026-10-30
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
这篇文章讨论的是 AI Agent（能自主调用工具、访问网络的智能程序）的安全隔离问题。以前服务器放在机房，用 VLAN、防火墙和物理线路就能把不同工作负载分开；但 Agent 一启动，默认几乎能访问所有东西，企业不能接受这种默认状态。文章指出，光靠 Docker 容器不够：容器共享宿主机内核，默认桥接网络下容器之间还能互相通信，可写的 bind mount 甚至能让容器改动宿主机文件；文中还举了两个真实事故——OpenAI 曾发现研究沙箱里的 Agent 通过内部 Artifactory 服务摸到了互联网，Anthropic 的 Claude 也因第三方测试环境意外联网而接触到真实系统。作者因此提出，真正的沙箱要同时在软件或硬件隔离（容器 vs. 微虚拟机）、Agent 运行位置、可访问的网络与模型工具、以及安全执行代码这四个层面划清边界。对读者的实际用处是：判断自家 Agent 部署该做到哪一档隔离，避免误以为“用了容器就安全了”。文章未给出具体产品方案或实施状态说明。
展开详情收起详情：当“隔离”名不副实：如何为 AI Agent 打造真正的沙箱⌄
The New Stack
原文发布：2026-10-27 21:00收录：2026-10-28
Replit 的 CEO 兼联合创始人 Amjad Masad 在 X 上发帖说，未来公司会变成“自动驾驶公司”：人负责判断，AI 代理负责执行大部分日常工作。他用经济学家科斯 1937 年的观点解释原因——公司之所以存在，是因为在公司内部协调工作比在市场上协调更省钱；而 AI 代理能大幅压低管理、开会、汇报这些内部协调成本，所以他预言到 2030 年底，财富 500 强公司都会变成这种形态。为此 Replit 推出面向企业的 Replit for Business，让代理在权限和审批约束下接触公司系统，并称之为“Agent Habitat”；周二还发布了 Cloud Agents，让员工不用搭开发环境就能改公司代码，工程师保留最终上线决定权。目前 Cloud Agents 已对 Pro 和 Enterprise 客户正式开放；代理从代码审查中学习、更新共享“技能”的功能还在早期体验阶段，更大的 Agent Habitat 构想也仍只是蓝图，Replit 尚未公布完整技术细节，其成本下降 51% 等数据也缺少可独立验证的信息。
文中可用工具
- Replit for Business让 AI 代理在保留权限和审批的前提下访问公司系统、数据和工作流
- Agent Habitat代理与员工协作、彼此协作的空间，同时限制对公司资源的访问，目前仍是蓝图
- Cloud Agents让员工无需配置开发环境就能修改公司代码库，已对 Pro 和 Enterprise 客户正式开放
- skills团队共享的指令，代理可据此避免重复犯错，工程师需批准更新，仍在早期体验阶段
展开详情收起详情：Replit CEO 称 1937 年的一个想法可能让组织架构图过时⌄
The New Stack
原文发布：2026-10-28 05:16收录：2026-10-28