内容浏览
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
今天暂时没有新上架内容，你可以继续浏览历史归档。
Asana 公司用 GPT-6 Astra 搭配 Codex，在浏览器智能体的测试里把模型成本降到原来的 76 分之一，速度也快了 5 倍。这样做是为了能给客户提供能力更强的模型。简单说，就是同样的任务花更少的钱、用更短的时间完成，省下来的资源可以支撑更强大的模型。目前这些数字来自测试环境，文中没有说明正式上线的时间，也没有给出具体怎么实现和更多细节。
Snyk 是一家做代码和云安全扫描的公司，它把原本只给自己客服团队用的一个 AI 助手，升级成了所有付费客户都能用的功能，叫 Snyk Assist。以前客户想问漏洞、账号或产品问题，得自己翻文档、文章和发布说明，或者提工单等回复，信息散落各处。这个助手用 LangChain、LangGraph 和 LangSmith 搭建，能用大白话回答并帮忙查漏洞、开工单、提需求，而且只会看到当前用户本来就有权查看的内容。它先内部试用了约一年，2026 年 4 月进入支持门户，9 月 1 日才放进核心产品，所以目前是已经可用的状态。对读者来说，问问题不用再等人工，也能在对话里直接完成一些操作。
Managed Deep Agents 在 v0.9 版本里新增了一个“表情回应”（reactions）API，用来给 Slack 频道里的智能体自动添加 emoji 反应。以前用户发出任务后，常常不知道智能体有没有收到、进行到哪一步，界面显得很“沉默”。这次的做法是：让开发者写一段简单规则或用一个决策模型，根据消息内容动态挑一个 emoji，比如看到“broken”就回一个虫子图标，表示已识别为故障。这样用户在等待较长的智能体任务时能得到即时反馈，更容易信任和看懂智能体在做什么。目前提到的是 v0.9 版本中的新能力，具体可用范围原文没有完整说明。
在北美 We Are Developers 大会上，Dynatrace 团队观察到开发者社区关注的三个趋势：智能体“管控”（沙箱隔离，防止智能体乱跑）、可观测性与评估（在生产环境中持续监控和评估智能体行为）、以及智能体体验（文档和接口专为智能体设计）。背景是智能体越来越多地进入生产环境，出现了失控和安全事件，问题往往出在缺乏隔离和监控。解决思路包括给智能体独立计算环境、把评估从开发阶段延伸到生产运行阶段、以及提供适合智能体读取的文档和接口。对读者而言，这意味着未来开发软件时，需要把智能体当作“用户”来设计基础设施，并重视运行时安全。文中还提到存储问题（大量遥测数据）尚未获得充分讨论，Dynatrace 用 Grail 数仓应对。
我们平时用AI模型聊天，其实底层就像在打电话，每次说话都要连着同一条线。普通网页聊天靠浏览器和服务器“黏”在一起还能凑合，但AI智能体可能短时间内发出几十个请求，中间还会跑去查资料、重试、出错，结果一旦服务器从一台扩到三台，请求被分到不同机器，就可能丢掉之前的对话，模型照样回复，却答得不对。文章用2014年微服务那套老办法来修：把对话历史从单台机器里拿出来，放到所有机器都能读写的共享存储里，这样任意一台机器都能接着聊。配套用Oracle AI Database Free做演示。对读者来说，这解释了为什么AI API不能直接照搬普通网页后端，并给出了一个可落地的改造方向。
作者把自己的 Azure 登录凭证直接交给一个 AI 编程智能体，然后测量它实际能碰到什么。结果发现：数据库只看到作者的名字、机器和工具，无法分辨是人还是智能体在执行，其中一个环境能删掉安全数据库里的数据，却偏偏没有审计记录。问题不在配置错误，而是整套身份设计默认“握着凭证的是人”，智能体借用人的身份后就继承了人的全部权限。这意味着你无法单独限制或吊销智能体的权限，也无法在事后证明某条查询是人还是机器跑的。
这篇文章讲的是 AI 代理（就是自动帮你干活的程序）在云上创建资源后没人管的问题。环境里有 34 个资源，比如网络、数据库和负载均衡器，有些已经几周没流量了，但标签上的“负责人”写的是 deploy-agent，根本查不到真人。以前员工离职至少有交接记录和上级接手，代理干完活后上下文一关，留下的东西就没人认领了。解决办法是用查询找出哪些资源的“负责人”其实是服务账号而不是真人，再用一条审批策略拦住新部署——除非每个资源都填了真人的邮箱，否则不允许通过。这样运维和财务就不会被遗忘的资源持续烧钱。
大多数 AI 事故响应工具还不能自己判断什么时候该介入处理故障，仍要等人发现问题或提前设定触发条件。Traversal 的联合创始人 Raaz Dwivedi 把智能体的自主程度分成三档：等人来问、按预设规则触发、自己主动判断何时介入；目前多数生产环境中的工具只停在前两档。10 月 22 日 The New Stack 将举办直播网络研讨会，届时会讨论如何让团队信任智能体自己做出这类判断，以及从第二档升到第三档需要满足哪些条件。至于具体怎么实现、有哪些限制，原文没有细说。
Harness 宣布收购了 Augment Code 的编程智能体产品，包括 Cosmos 软件工厂等，想解决的是：代码生成变快了，但测试和发布流程没跟上，反而成了瓶颈。他们计划让智能体在写代码时参考过去的部署失败记录，自动修复问题，但这项整合功能还没上线，具体怎么交换信息、权限怎么分配都没说清楚。目前 Cosmos 仍可在原网站使用，程序员依然要人工审核代码。对读者来说，如果团队用这套工具，现在只能用到基础功能，真正好用的部分还得等。
Spotify 的工程师 Pratik Rasam 在一场演讲中介绍了 Spotify Ads Manager 如何用 Google ADK Java 在生产环境大规模运行多智能体系统。多智能体系统就是让多个 AI 程序各管一块任务、协同工作；规模一大就容易变成难以维护的“单体巨兽”，也难控制成本。他分享了架构模式、领域归属、确定性护栏和基于追踪的评估策略，以及划定智能体边界、优化工具结构、控制成本等经验教训。目前这是演讲分享，材料未说明具体落地成效或可复用代码。
Stripe 做了一个叫 Restock 的示范智能体，它住在 Slack 里，能帮你在网上找商品、把商品放进购物车并完成付款。以前让 AI 自己花钱很麻烦：要么让它在网页上模拟点按结账，容易出错，要么得把银行卡信息交给模型，很不安全。这次的做法是让付款交给 Stripe 的消费者钱包 Link 处理，模型从头到尾看不到卡号，而且用户要在 Slack 里确认订单并设定花钱上限，比如买一盒 25 美元以内的蓝笔，智能体最多只能花这么多。对读者的意义是，可以从 Restock 的示例代码出发，自己搭一个能安全付款的智能体。
一群曾参与 OpenSearch 的工程师创立了 Infino，推出面向 AI 智能体的统一检索层。过去，智能体要查数据得分别对接数据仓库、搜索引擎、向量数据库，还要用 ETL 管道同步，查询繁琐、成本高。Infino 把数据以 Parquet 格式存到对象存储，用一条 SQL 就能同时完成关键词搜索、语义搜索、过滤、聚合和连接，省去多个系统和胶水代码，还能集中管理权限。对开发者来说，接入更简单、花费更低，核心引擎已在 GitHub 开源（Apache-2.0），Infino Cloud 托管服务也同时推出，但其中部分专有功能需付费使用。
Hannah Foxwell 分享了智能体编程兴起后，工程负责人需要重新思考团队协作方式。她提出三个关键抓手：只做值得做的软件、把自动化安全放在速度之前、用「破梳型」通才技能和可持续的值班制度保住人的位置。原文只是演讲摘要，没有给出具体实施步骤，也未说明这些观点基于哪些案例或数据。
提供的材料未提及具体可用工具。
LangChain 发布了 Managed Deep Agents v0.9。以前智能体只能按固定方式运行，现在它们能在聊天中自己创建提醒和重复任务，每次运行前还能重新选择用哪个模型、哪些技能和工具，不用为每个团队复制一份。智能体还能在回复前先在 Slack 消息上点个表情，告诉对方“收到了”。目前这个版本处于公开测试阶段，想用的人可以开始试用。
Deep Agents 是一个用来搭建 AI 智能体的工具，技能则是教智能体做特定事情（比如准备客户会议）的说明文件。过去技能和工具是分开管理的，技能一多就容易占用智能体宝贵的上下文空间，还可能先调用工具却没读过使用说明。这次改版让工具可以绑定在技能上，只有读了技能才会加载对应工具，还支持在对话开始时锁定某个技能、以及在不重开对话的情况下重新加载技能。对使用者来说，长期运行的智能体可以带着成千上万个技能而不挤爆上下文，响应更快、行为更可控。
GitHub 正在一边保持线上服务运行，一边重建它的 Git 底层存储系统。过去每个仓库都在多台文件服务器上保存完整副本，加副本能加快读取，但每次写入也要同步所有副本，于是读扩展越多、写就越慢，难以承受成千上万个 AI 智能体并发提交。新架构的目标是把“数据持久保存”和“读取扩容”拆开，让写入不再被最慢的副本拖累。对普通开发者的直接好处是更快的推送、克隆和 CI，尤其是每天产生海量提交的仓库；目前这还只是重建工作的介绍，没有说明具体上线时间、迁移步骤和性能数据。
提供的材料未提及具体可用工具。
OpenAI 和 Ironclad 正在合作训练和评估 AI 智能体，让它们处理复杂的合同工作流程。原先 AI 操作电脑做专业工作的能力还不够强，这次通过把合同这类真实业务场景作为训练和测试环境来改进。对读者来说，这意味着未来 AI 可能更可靠地帮你完成合同处理等专业电脑任务。目前原文只提到训练和评估，没有说明具体工具、开放时间或是否已可用。
提供的材料未提及具体可用工具。
Dynatrace 是一家做应用和基础设施监控软件的公司，它推出了一款叫 Bluebox 的 AI 智能体，想让工程师的工作更轻松。以前监控工具一出问题就拼命发告警，工程师得自己排查、写修复代码，很费时间。Bluebox 会把团队的代码和线上实际运行数据做对比，然后直接生成一个修复补丁（pull request），工程师可以审核后决定是否采用，也可以让它自动运行。它还能把告警和修复建议推送到 Claude、Codex 这些开发者已经在用的工具里，不用再开一个新面板。Dynatrace 仍然提醒客户：批准修复前要先检查，别完全信任 AI 的输出。目前 Bluebox 在七月发布，已可以使用，但公司希望未来 12 到 18 个月团队能逐渐给智能体更多自主权。
Elastic 的 Susan Chang 讲述了他们公司如何把 AI 智能体（agent）的测试评估从零散、各自为政的做法，改造成一套统一、可用于生产环境的评估框架。原来的问题是：不同团队各测各的，方法随意，出了问题难以及时发现。她的解决思路包括：把“让大模型当裁判”和“写死规则判断”两种评估方式结合起来；把数据科学家常用的 Python 评估代码和生产环境用的 TypeScript 代码打通；再配合深度追踪，在复杂的 RAG（检索增强生成）和安全场景中抓出性能退步，同时不丢失业务上下文。对读者的用处是：如果你的团队也在做 AI 智能体产品，这套经验能帮你建立更靠谱、更可复用的评估流程。
提供的材料未提及具体可用工具。
Anthropic、Linear 和 Depot 在九月先后指出：智能体写代码太快，把持续集成（CI，即每次提交代码后自动跑测试的流水线）压成了瓶颈。Anthropic 的 CI 任务量半年涨了 25 倍，工程师每季度交付的代码约为 2021 至 2025 年的 8 倍；Linear 的测试套件自一月以来翻了近两番。业界的反应是让流水线更快，但作者认为这解决错了层面：云原生系统里一个仓库只是几十个服务之一，CI 只验证仓库里的代码和模拟（mock）出来的依赖，跨服务边界才出问题。真正该做的是把验证提前到提交 PR 之前、并且针对整个系统而非单个仓库，再用共享的 Kubernetes 集群多路复用来控制成本。读者会得到判断：智能体时代不能只靠提速，还要改变验证的对象和时机。