Workday 把自己的 HR 和财务数据平台「无头化」——简单说，就是不再只靠自家网页界面来用，而是开放接口给外部程序。以前开发者想接这些数据，常把数据复制到数据湖或用系统账号，结果绕过了权限检查，智能体可能看到不该看的信息、做不该做的操作。现在通过官方的 MCP 服务器、SQL 直查和共享运行时，智能体能以用户本人的身份运行，只能看到、操作该用户有权处理的内容。对开发者来说，可以在 Claude Code、Cursor 等工具里构建自己的 HR 和财务智能体；对企业来说，智能体仍受 Workday 的权限和审计约束。
文中可用工具
- Model Context Protocol一种让 AI 智能体连接外部数据与工具的开放协议
- MCP serverWorkday 提供的入口，让智能体以用户身份访问 HR 和财务数据
- Workday Extend AI包含 Agent-Ready Tools 的开发工具集
- Agent-Ready ToolsWorkday 的 MCP 工具服务器，提供读写数据的工具
- Live Data Query允许 BI 工具和智能体直接对 Workday 数据跑 SQL 查询
- Workday Data Cloud包含 Live Data Query 的数据云服务
- Agent Harness共享运行时，负责给智能体传身份权限并挑选模型
- Developer Agent用自然语言在 Claude Code、Codex、Cursor 等工具里生成 Workday 智能体和应用
- Custom Agents让团队把用 LangChain 或 Google ADK 构建的智能体部署到 Agent Harness
- Agent Context Service计划 2027 年初早期访问，只预加载任务所需的 Workday 数据
- Grounded Reasoning计划 2027 年初早期访问，在执行动作前拿企业政策、流程规则和 Workday 记录做核查
- Claude Code外部开发者用来构建 HR 和财务智能体的工具之一
展开详情收起详情：Workday 走向无头化，向外部 AI 智能体开放 HR 与财务数据⌄
原文发布：2026-10-13 21:00 · 首次收录：2026-10-14
CloudBolt 的首席客户官 Shawn Petty 和售前工程总监 Mike Bombard 在一次网络研讨会上，分享了他们对客户和潜在客户环境的检查结果：超过 20% 与 MCP 相关的访问策略要么失效要么缺失，多数情况下 MCP 服务器跑在某个人的私人令牌上，而不是服务账号。这带来的麻烦是出事后审计日志查不清责任：私人令牌会把某个工程师的名字写进日志，共享服务账号则只留下账号名，两种都说不准到底是谁下的指令、谁批准了这次访问。他们演示的做法是把 Agent 的活动对接到企业已有的身份提供商，限制 Agent 能碰哪些资源，再读出可追溯的审计记录。对用 Agent 操作云基础设施的团队来说，这提供了一个把 Agent 行为追责到具体人的思路；该研讨会需注册后参加，具体产品能力原文未说明。
文中可用工具
- CloudBolt把 Agent 活动对接到已有身份提供商、限制 Agent 可访问范围并输出审计记录的方案
展开详情收起详情：Agent 干了活，审计日志却说不出是谁下的指令⌄
原文发布：2026-10-13 23:00 · 首次收录：2026-10-14
Harness 和 Cosmos 想把软件开发变成一条受管控的“流水线”：Harness 负责把代码变更安全送进生产环境，并在构建、测试、安全和部署等环节留下证据；Cosmos 负责用事件触发并协调各种 AI 代理，按固定流程把规格变成 PR、把告警变成修复。过去企业担心自动化流程不可信、不可控，这次的做法是让代理只在受限制的容器里运行、令牌按次发放、策略不通过就不执行，变更失败还能自动回滚。对读者来说，这意味着未来更多重复性工程工作可由流程化代理完成，人只在关键检查点审批，但目前材料没有说明具体可用时间、价格或独立验证结果。
文中可用工具
- Harness软件交付平台，用受治理的流水线把代码变更安全送进生产环境
- Cosmos代理编排平台，用来搭建按事件启动、按流程协调代理的软件工厂
- Delegates在客户自己的 VPC 或 Kubernetes 集群里执行流水线任务的组件
- OPA策略引擎，用来拦截不符合规定的生产流水线变更
- MCP原文仅提到代理的网络访问被限制在获批准的 MCP 服务器
展开详情收起详情：受治理的软件工厂：Harness 与 Cosmos⌄
原文发布：2026-10-13 18:24 · 首次收录：2026-10-14
LangChain 把 ScaleDown 的专用小模型接进了 Deep Agents 和 LangChain 智能体框架里。原来长时间运行的智能体上下文会越堆越满，而用通用大模型去摘要历史、压缩工具结果又慢又贵。现在换成专门做单一任务的 ScaleDown 模型（摘要、压缩、抽取、分类），官方称这些窄任务上比前沿模型快 200 倍、便宜 467 倍，单次最多能读 100 万 token，还能直接处理图片和扫描 PDF。做智能体的开发者可以借此降低每次决策的成本和延迟，也可通过 LangSmith LLM Gateway 追踪调用和用量。
文中可用工具
- ScaleDown一组专做摘要、压缩、抽取、分类等单一任务的模型，用来更快更便宜地管理智能体上下文
- Deep Agents用于构建长时间运行智能体的框架，可挂载摘要与工具结果压缩中间件
- LangChain搭建智能体的开发框架，支持 create_agent 并接入 ScaleDown 中间件
- langchain-scaledown把 ScaleDown 模型接入 LangChain 与 Deep Agents 的集成包，自带三种中间件
- ScaledownSummarizationMiddleware替换 Deep Agents 自带的摘要中间件，用 ScaleDown 生成历史摘要
- ScaledownToolCompressionMiddleware在工具结果进入模型前，只保留与查询相关的部分
- LangSmith LLM Gateway已支持 ScaleDown，可追踪调用并计入消费和速率限制
- Jev文中用来对比的决策模型，只接受文本、每题最多 32K token 状态
展开详情收起详情：用 ScaleDown 与 Deep Agents 构建长时间运行的智能体⌄
原文发布：2026-10-13 22:01 · 首次收录：2026-10-14
LangChain 给自家的编程智能体 Deep Agents CLI 换了一套围绕模型的“外骨架”（系统提示、工具和中间件），用来引导模型的能力。原来的做法缺少测试和验证，智能体常写完代码、自己看一遍就停下，导致成绩只有 52.8 分，排在 Terminal Bench 2.0 榜单 30 名开外。这次他们加了强制自检清单、注入目录与工具环境信息、以及时间预算提醒，还用追踪数据自动分析失败原因，成绩提升 13.7 分到 66.5 分，进入前五。对读者的意义是：不改模型本身，靠工程化外围设计也能明显提升智能体表现；不过其追踪分析技能尚未发布，仍在测试中。
文中可用工具
- Deep Agents CLILangChain 的编程智能体，本次改进的对象
- Terminal Bench 2.0评估智能体编程能力的基准测试，共 89 个任务
- Harbor用于编排测试运行的框架
- Daytona提供沙箱环境运行测试
- LangSmith存储智能体每步操作及延迟、token 数、成本等指标
- GPT-5.2-Codex本次实验中固定使用的模型
- PreCompletionChecklistMiddleware在智能体退出前拦截，提醒其对照任务要求做验证
- LocalContextMiddleware启动时扫描工作目录和工具环境，把上下文注入给智能体
展开详情收起详情：通过 harness 工程改进 Deep Agents⌄
原文发布：2026-10-14 03:56 · 首次收录：2026-10-14
LangChain 团队开源的 Deep Agents SDK 是一个帮开发者搭建 AI 智能体的工具包，这类智能体可以自己规划任务、派生子智能体、读写文件，去完成耗时很长的工作。问题是任务一长，对话内容就会超出模型能记住的容量，导致 AI「忘事」、表现变差。为此它用三招省内存：工具返回内容超过 2 万 token 就存到文件系统里，只留一个路径和前 10 行预览；上下文用到 85% 时，把旧的写文件操作替换成文件路径，不再重复占位置；再不够就把整段对话压缩成一份摘要，同时把原始记录完整存进文件系统，需要时再查回来。这样开发者能让 AI 长时间干活而不容易「失忆」。
文中可用工具
- Deep Agents SDKLangChain 开源的智能体开发工具包，内置任务规划、子智能体和文件系统能力
- LangChain model profiles在底层提供某个模型上下文窗口的 token 阈值，用于判断何时压缩上下文
- read_file读取之前被移出上下文、存到文件系统的消息内容
- terminal-bench用于跑真实任务、观察上下文压缩效果的基准测试
展开详情收起详情：Deep Agents 的上下文管理机制⌄
原文发布：2026-10-14 03:56 · 首次收录：2026-10-14
LangChain 团队用 Deep Agents 测试框架跑了一批开放权重模型，发现 GLM-5 和 MiniMax M2.7 在文件操作、工具调用、指令遵循这些智能体核心任务上，已经和 Claude Opus 4.6、GPT-5.4 等闭源顶级模型打得差不多。过去用闭源大模型跑智能体，又贵又慢：每天输出 1000 万 token，Opus 4.6 大约要 250 美元，MiniMax M2.7 只要约 12 美元，一年差出近 8.7 万美元。开源模型还能跑在 Groq、Baseten 这类专门优化的推理服务上，延迟和吞吐都更好。不过这还只是早期评测结果，团队正在继续扩充测试集；普通用户暂时用不上，主要意义是给要做智能体产品的开发者一个更便宜、更快的选择。
文中可用工具
- Deep AgentsLangChain 的智能体测试与运行框架，用来统一跑评测和部署智能体
- GLM-5z.ai 推出的开放权重模型，本次评测中表现接近闭源顶级模型
- MiniMax M2.7MiniMax 推出的开放权重模型，成本最低，本次评测中表现接近闭源顶级模型
- Ollama本地运行模型的工具，可跑私有化开源模型
- vLLM高性能推理引擎，用于自行部署开源模型
- Baseten模型托管推理服务，本次用于跑 GLM-5
- OpenRouter模型调用聚合平台，提供 MiniMax M2.7 等模型的调用
- Groq专注低延迟高吞吐的推理服务商
- Fireworks面向生产场景的模型推理服务商
- SWE-Rebench软件工程类公开评测基准
- Terminal Bench 2.0终端操作类公开评测基准
- LangSmithLangChain 的评测与可观测平台，公开分享本次评测运行结果
展开详情收起详情：开源模型已跨过临界点⌄
原文发布：2026-10-14 03:56 · 首次收录：2026-10-14
LangChain 今天发布了 Deep Agents Deploy 的测试版，它能让开发者用一条命令把自定义 AI 智能体部署到生产环境。此前，部署一个智能体需要自己搭建可扩展的服务器、为每次会话创建沙箱、再接通各种接口，步骤繁琐。这次它把这些打包成 `deepagents deploy`，你只需指定模型、指令文件、技能和工具配置即可上线，而且底层用的是开源、不绑定任何模型厂商的框架，所以智能体的记忆存在你自己的数据库里，换模型或换平台时不用从零开始。目前是 beta 测试版，记忆格式用 AGENTS.md 等标准文件保存，支持通过 API 直接查询。
文中可用工具
- Deep Agents开源、不绑定模型厂商的智能体框架，用来搭建自定义智能体
- Deep Agents deploy一条命令把智能体部署到生产环境的工具，当前为 beta 版
- LangSmith Deployment生产级、可横向扩展的服务器，Deep Agents deploy 底层用它来托管智能体
- AGENTS.md存放智能体核心指令的开放标准文件
- Agent Skills通过 markdown 文件提供专门知识、通过脚本执行动作的开放标准
- MCP一种让智能体调用工具的协议，也用于把部署的智能体当作工具调用
- A2A一种让多个智能体互相调用的协议，用于多智能体协作场景
- Agent Protocol一套接口标准，方便开发者写界面与部署的智能体交互
- Daytona沙箱服务商，让智能体在隔离环境中运行代码和技能
- Runloop沙箱服务商，让智能体在隔离环境中运行代码和技能
- Modal沙箱服务商，让智能体在隔离环境中运行代码和技能
- LangSmith Sandboxes沙箱服务，让智能体在隔离环境中运行代码和技能
展开详情收起详情：Deep Agents Deploy：Claude Managed Agents 的开源替代方案⌄
原文发布：2026-10-14 03:56 · 首次收录：2026-10-14
LangChain 把 MCP 支持搬进了主包，现在放在 langchain.mcp 里，不再需要单独安装 langchain-mcp-adapters。MCP 是一种让 AI 智能体调用外部工具的通用协议，过去每次调用都要先开一个会话、记住会话编号，服务器一重新部署，正在进行的会话就断了，运维起来很麻烦。新版 MCP 规范改成了“无状态”，所以 LangChain 顺势支持了工具列表缓存，以及 elicitation（工具执行中途反过来问用户问题，比如确认删除或补充缺失参数），并用 LangGraph 的 interrupt 来实现这种暂停和恢复。底层用的是 FastMCP，新旧两版协议的服务器都能连，旧的 MultiServerMCPClient 收敛成单个 MCPAdapter 类。对开发者来说，装个 langchain[mcp] 就能用，不过迁移细节和 elicitation 后续示例在文中被截断了，这部分信息未完整给出。
文中可用工具
- langchain.mcpLangChain 主包里的 MCP 支持模块，用来连接智能体和 MCP 工具服务器
- FastMCP提供连接、认证、缓存和协议协商的底层客户端，兼容新旧两版 MCP 规范
- MCPAdapter替代旧的 MultiServerMCPClient，用来接入一个或多个 MCP 服务器
- ClientGroup给每个 MCP 服务器单独配置连接、认证和协议版本
- LangGraph用其中的 interrupt 机制实现 elicitation 的暂停与恢复
- create_deep_agent创建可直接使用 MCP 工具的智能体
- langchain-mcp-adapters旧的独立安装包，现已并入 langchain 主包
展开详情收起详情：LangChain 中的 MCP：无状态协议、elicitation 等更新⌄
原文发布：2026-10-14 03:56 · 首次收录：2026-10-14
一位在 Bit Cloud 工作的工程师做了个实验：把之前用 Claude Code 搭建的小型客服控制台放在 Bit 平台上，每个组件版本化时平台会自动记录依赖关系。他开了一个全新的 Claude Code 会话，没有聊天历史、没有本地代码，只让 AI 加一个按工单状态和负责人筛选的功能。Claude 通过 MCP 先读整个 scope，再读各组件，两次调用就发现了四个组件以及它们共享的工单实体，随后自动导入代码、改完前端并跑通 41 个测试。这样做的价值是：AI 不用重新猜你的架构，还能知道共享部分不要乱动。不过记录只能说明“谁依赖谁”，不能说明接口行为是否还对得上，这部分仍需人工检查。作者也说明这是演示项目，用的是预置账号和公开签名密钥，并发控制、迁移、恢复流程和必跑的数据库测试都还没做。
文中可用工具
- Claude CodeAI 编程助手，可在会话中读取项目上下文并修改代码
- MCP让 Claude Code 连接外部平台读取组件与依赖信息的协议
- Bit Cloud构建、托管和部署组件的平台，会在版本化时生成依赖记录
- read_scopeMCP 调用，读取一个 scope 下所有组件及其依赖
- read_componentsMCP 调用，读取指定组件的 API 参考和文件清单
- bit import把远程组件导入本地工作区
- CLAUDE.md人工编写的项目指令文件，会话开始时加载
- AGENTS.md通用的智能体指令文件，告诉 AI 去平台上查找信息
- ProjectsClaude Code 云会话中的共享记忆功能，可在多个会话间记住决定
- React前端框架，用于构建客服控制台界面
- Express后端服务框架，提供工单 API
- MongoDB数据库，存储工单和评论数据
展开详情收起详情：Claude Code 两次 MCP 调用就找到应用共享契约，但记录到此为止⌄
原文发布：2026-10-11 22:00 · 首次收录：2026-10-12
AI Agent 上线后服务运行正常，但回答质量有没有变好？问题在于：训练模型的工程师知道什么叫“好答案”，运维团队只看服务是否在线，两边看不同的仪表盘，评估集慢慢过时也没人更新。CoreWeave 在 Fully Connected 2026 大会上发布 Forge，把运行、观察、整理数据、改进、评估五个环节放进同一个开发环境，用 CoreWeave Registry、Weights & Biases Models 等工具保留从模型版本到生产例子的完整记录，让团队能定位失败、选择改法，并在上线前证明新版本确实更好。目前 CoreWeave ARIA 和 CoreWeave Sandboxes 已正式可用，Agent Lens、Notebooks、Model Distillation 处于预览阶段；MasterClass 和 Canva 已开始使用 Forge。
文中可用工具
- CoreWeave Forge把运行、观察、整理数据、改进和评估五个环节集中到一个开发环境
- CoreWeave Registry管理模型、Agent 和数据集
- Weights & Biases Models追踪实验、超参数搜索、分析和自动化工作流
- CoreWeave Agent Lens追踪 Agent 的步骤、决策和工具调用，并监控线上流量
- CoreWeave Notebooks提供托管的 Python notebook，用于共享评估和自定义分析
- CoreWeave ARIA分析运行结果、提出实验建议、推荐代码改动
- CoreWeave Sandboxes为 Agent、工具调用、强化学习和评估提供隔离的 CPU 或 GPU 环境
- Serverless SFT无需训练集群即可用生产信号做有监督微调
- Serverless RL让团队用自己的训练配方做强化学习实验
- Model Distillation用大模型输出训练更小的开放权重模型，并与原模型对比打分
- Serverless Inference访问开放权重模型的推理服务，基础设施由 CoreWeave 管理
- Dedicated Inference在隔离基础设施上运行推理，团队控制模型权重、部署设置和 GPU 资源
展开详情收起详情：如何将 AI 生产反馈转化为更好的 Agent⌄
原文发布：2026-10-11 00:00 · 首次收录：2026-10-11
决策模型是一种专门给 AI 应用做“选择题”的模型：它接收应用状态，返回带概率的选项答案，不写文字也不解释理由。TypeSafe AI 最先推出 Jev 以及请求/响应的 schema，随后 AWS 的 Strands Decider 2B、Upstage 的 Solar Decide、Ollama 0.35 等纷纷照搬同一套接口，OpenRouter、Perplexity 也支持同类 choice、noul（是/否）、score 问题类型。这样一来，开发者只要改一个 base URL，就能在不同厂商甚至本地运行的决策模型之间迁移，而不必重写决策逻辑；不过各家在选项上限、置信度算法和答案质量上仍有差异，切换前需要测试。OpenAI 虽在 DevDay 发布了基于 GPT-6 Luna 的 Decisions API，但仍在有限预览，未公布 schema 和价格，尚未加入这套统一接口。
文中可用工具
- Strands Decider 2BAWS 发布的开权重决策模型，在 /v1/systemone 端点按 System One 接口返回决策答案
- JevTypeSafe AI 推出的决策模型，也是 System One API 的原始实现
- Solar DecideUpstage 的托管决策模型，通过 System One schema 提供服务
- Ollama本地模型运行时，0.35 版本新增 /v1/systemone 端点
- OpenRouter模型路由服务，提供 Jev Router 和与 TypeSafe 兼容的 Decisions API 路由
- Perplexity Decisions API托管决策服务，支持 choice、noul、score 三类问题
- OpenAI Decisions APIOpenAI 基于 GPT-6 Luna 的决策服务，仍在有限预览，未公布 schema 和价格
- BifrostMaxim AI 的网关，在 Jev 不可达时把决策转发给 LLM 并以相同格式返回答案
- Strands Agents智能体框架，其 before_tool_call 事件可被用来在工具调用前做决策门控
- TypeSafe SDKTypeSafe 提供的开发包，改 base URL 即可对接任何实现 System One API 的服务器
- SGLang本地运行时，暴露与 System One 相同的接口
- Open-Jev社区构建的决策模型，提供 System One 接口
展开详情收起详情：AWS、Upstage 与 Ollama 就决策模型 API 达成一致，OpenAI 尚未加入⌄
原文发布：2026-10-09 20:00 · 首次收录：2026-10-10
Netflix 的两位工程师 Prasanna Vijayanathan 和 Renzo Sanchez-Silva 分享了一个演讲，讲他们怎么处理每秒 3800 万条事件量级的监控难题。原来的做法是出问题才被动告警，现在他们改用一套由 AI 驱动的“运营本体”，配合 Claude 和图层数据库来做自动化处理。具体是把 MELT（指标、事件、日志、追踪）这四类监控数据统一成可以查询的知识图谱，让系统能自动分诊、找根因，甚至自己修复故障。对读者来说，这展示了一条用 AI 把海量监控数据变成自动化运维能力的大规模落地思路。
文中可用工具
- Claude用于构建智能体工作流，实现自动化运维处理
- graph databases存储统一后的监控数据，形成可查询的知识图谱，支持自动分诊与根因分析
展开详情收起详情：演讲：本体驱动的可观测性——在 Netflix 规模上构建端到端知识图谱⌄
原文发布：2026-10-09 19:00 · 首次收录：2026-10-10
Snyk 是一家做代码和云安全扫描的公司，它把原本只给自己客服团队用的一个 AI 助手，升级成了所有付费客户都能用的功能，叫 Snyk Assist。以前客户想问漏洞、账号或产品问题，得自己翻文档、文章和发布说明，或者提工单等回复，信息散落各处。这个助手用 LangChain、LangGraph 和 LangSmith 搭建，能用大白话回答并帮忙查漏洞、开工单、提需求，而且只会看到当前用户本来就有权查看的内容。它先内部试用了约一年，2026 年 4 月进入支持门户，9 月 1 日才放进核心产品，所以目前是已经可用的状态。对读者来说，问问题不用再等人工，也能在对话里直接完成一些操作。
文中可用工具
- LangChain搭建 AI 智能体的开发框架，提供社区和生态支持
- LangGraph运行智能体的单一运行时，支撑多个入口
- LangSmith观测和评估智能体表现，帮助发现退化、改进回答
- Snyk Assist面向付费客户的对话式 AI 助手，可回答问题并代用户操作
- SlackSnyk Assist 的一个使用入口（Slack 应用）
展开详情收起详情：Snyk 如何将内部支持智能体转化为面向客户的产品功能⌄
原文发布：2026-10-09 18:29 · 首次收录：2026-10-10
Managed Deep Agents 在 v0.9 版本里新增了一个“表情回应”（reactions）API，用来给 Slack 频道里的智能体自动添加 emoji 反应。以前用户发出任务后，常常不知道智能体有没有收到、进行到哪一步，界面显得很“沉默”。这次的做法是：让开发者写一段简单规则或用一个决策模型，根据消息内容动态挑一个 emoji，比如看到“broken”就回一个虫子图标，表示已识别为故障。这样用户在等待较长的智能体任务时能得到即时反馈，更容易信任和看懂智能体在做什么。目前提到的是 v0.9 版本中的新能力，具体可用范围原文没有完整说明。
文中可用工具
- Managed Deep Agents管理分布式智能体的平台，新增 reactions API，可根据消息自动添加 emoji 反应
- Slack channels在 Slack 频道中承载智能体并展示 emoji 反应
- Jev一种决策模型，可从预设的 emoji 词表中根据上下文挑选一个
- TypeSafe ClassifierLangChain 工具包中的分类器，用于调用兼容 TypeSafe 的决策模型
- SemIf另一种可配合相同接口使用的决策模型
- LangSmith LLM Gateway托管决策模型的网关，原文提到 SemIf 托管于此
展开详情收起详情：如何用 Managed Deep Agents 打造出色的开箱即用用户体验⌄
原文发布：2026-10-10 03:34 · 首次收录：2026-10-10
在北美 We Are Developers 大会上，Dynatrace 团队观察到开发者社区关注的三个趋势：智能体“管控”（沙箱隔离，防止智能体乱跑）、可观测性与评估（在生产环境中持续监控和评估智能体行为）、以及智能体体验（文档和接口专为智能体设计）。背景是智能体越来越多地进入生产环境，出现了失控和安全事件，问题往往出在缺乏隔离和监控。解决思路包括给智能体独立计算环境、把评估从开发阶段延伸到生产运行阶段、以及提供适合智能体读取的文档和接口。对读者而言，这意味着未来开发软件时，需要把智能体当作“用户”来设计基础设施，并重视运行时安全。文中还提到存储问题（大量遥测数据）尚未获得充分讨论，Dynatrace 用 Grail 数仓应对。
文中可用工具
- BlueBoxDynatrace 推出的 AI 智能体，帮助其他智能体获取可观测性和运行时上下文
- GrailDynatrace 的统一数据湖仓，用于处理智能体产生的大量遥测数据
- MCP一种让智能体访问外部工具和数据的接口协议
- llms.txt一种供大语言模型读取的文档文件，帮助智能体理解网站内容
展开详情收起详情：管控、观测、适配：塑造智能体软件开发的三大趋势⌄
原文发布：2026-10-09 04:49 · 首次收录：2026-10-09
我们平时用AI模型聊天，其实底层就像在打电话，每次说话都要连着同一条线。普通网页聊天靠浏览器和服务器“黏”在一起还能凑合，但AI智能体可能短时间内发出几十个请求，中间还会跑去查资料、重试、出错，结果一旦服务器从一台扩到三台，请求被分到不同机器，就可能丢掉之前的对话，模型照样回复，却答得不对。文章用2014年微服务那套老办法来修：把对话历史从单台机器里拿出来，放到所有机器都能读写的共享存储里，这样任意一台机器都能接着聊。配套用Oracle AI Database Free做演示。对读者来说，这解释了为什么AI API不能直接照搬普通网页后端，并给出了一个可落地的改造方向。
文中可用工具
- OpenAI SDK把官方客户端接到兼容的推理接口上，维持多轮智能体对话
- Oracle AI Database Free作为共享存储，保存对话状态，支撑多台机器一起服务
展开详情收起详情：为AI应用构建可扩展且对智能体友好的API⌄
原文发布：2026-10-08 19:00 · 首次收录：2026-10-09
作者把自己的 Azure 登录凭证直接交给一个 AI 编程智能体，然后测量它实际能碰到什么。结果发现：数据库只看到作者的名字、机器和工具，无法分辨是人还是智能体在执行，其中一个环境能删掉安全数据库里的数据，却偏偏没有审计记录。问题不在配置错误，而是整套身份设计默认“握着凭证的是人”，智能体借用人的身份后就继承了人的全部权限。这意味着你无法单独限制或吊销智能体的权限，也无法在事后证明某条查询是人还是机器跑的。
文中可用工具
- Azure CLI缓存用户的登录令牌，供其他工具直接调用
- sqlcmd命令行连接 SQL 数据库并执行查询
- Azure提供云资源与身份认证的凭证体系
展开详情收起详情：审计日志写着我的名字：把凭证交给智能体时，它到底继承了什么⌄
原文发布：2026-10-08 23:00 · 首次收录：2026-10-09
这篇文章讲的是 AI 代理（就是自动帮你干活的程序）在云上创建资源后没人管的问题。环境里有 34 个资源，比如网络、数据库和负载均衡器，有些已经几周没流量了，但标签上的“负责人”写的是 deploy-agent，根本查不到真人。以前员工离职至少有交接记录和上级接手，代理干完活后上下文一关，留下的东西就没人认领了。解决办法是用查询找出哪些资源的“负责人”其实是服务账号而不是真人，再用一条审批策略拦住新部署——除非每个资源都填了真人的邮箱，否则不允许通过。这样运维和财务就不会被遗忘的资源持续烧钱。
文中可用工具
- CloudQuery查询云资源的资产清单，找出负责人标签指向机器账号而非真人的资源
- env zero管理和审批环境部署的平台，用策略确保每个资源都有真人负责
- env zero API keys给代理分配受限权限的密钥，避免使用管理员级别的共享凭证
- env zero agent CLI让代理以独立受限身份认证，而不是共用令牌
展开详情收起详情：你的 AI 代理刚刚创建了资源，谁来负责？⌄
原文发布：2026-10-09 00:00 · 首次收录：2026-10-09
大多数 AI 事故响应工具还不能自己判断什么时候该介入处理故障，仍要等人发现问题或提前设定触发条件。Traversal 的联合创始人 Raaz Dwivedi 把智能体的自主程度分成三档：等人来问、按预设规则触发、自己主动判断何时介入；目前多数生产环境中的工具只停在前两档。10 月 22 日 The New Stack 将举办直播网络研讨会，届时会讨论如何让团队信任智能体自己做出这类判断，以及从第二档升到第三档需要满足哪些条件。至于具体怎么实现、有哪些限制，原文没有细说。
文中可用工具
- AI SRE用于事故排查和响应、辅助运维的 AI 工具，文中未说明具体产品形态
- Traversal Workers据文中描述已具备主动判断何时介入的智能体
展开详情收起详情：多数 AI 事故响应工具仍把关键决策留给人⌄
原文发布：2026-10-20 19:13 · 首次收录：2026-10-09