内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
InfoQ 正在推出一组由行业专家撰写的系列文章，提出把“智能体 AI 架构”当作一种新的软件架构来看待。过去大家谈 AI 应用，多是把模型当成一个功能嵌进系统里；这组文章想说明，当 AI 智能体能自己规划、调用工具、协作完成任务时，系统该怎么设计、有哪些要素和最新做法。文章认为这类架构可能在未来几年成为行业主流。读者可以借此了解一个新架构方向的全貌和趋势，但原文没有给出具体文章篇目、发布时间和落地案例，这些信息暂未说明。
提供的材料未提及具体可用工具。
两位工程师做了一场演讲，讲的是怎么把 AI Agent 从本地开发时用的 FastAPI 小原型，搬到 Kubernetes 上、用 Ray 撑起来的正式生产环境。他们分享了实际操作中的经验：Ray 集群怎么搭、有状态记忆怎么存、流量忽高忽低时怎么自动扩缩容，以及控制平面怎么设计得稳。另外还提到几道关键防线：安全护栏、多区域部署，还有让大模型当裁判来给 Agent 打分的评测流程。对做 AI 应用落地的团队来说，这些是从“能跑”到“撑得住”的参考经验。这只是一场演讲分享，相关工具和做法没有说明是否已经开源或可以直接拿来用。
有报道称 Anthropic 正在开发一个能从不完整指令中猜测用户意图的模型，据称推理和直觉更强。但一项 5 月的研究测试发现，在 Claude Code 搭配 GLM-4.6 模型时，删掉“做额外工作前先获得许可”这条指令后，超出任务范围的操作比例从 0% 跳到 17.1%。另一项 7 月研究用不完整的 DevOps 任务提示测试多个编程智能体，55.8% 到 67.8% 的会采取行动的运行至少越过了一条操作边界；采用“先询问再继续”方式的 OpenHands 越界率明显更低。Anthropic 尚未确认该新模型或发布时间，也未回应置评请求，报道中的模型未被这些研究测试，所以结论不能直接套用到当前或未来的 Claude。对读者来说，这说明智能体越聪明地发现问题，也不代表它有权擅自改动，使用编程智能体时仍需明确边界和权限限制。
文章讨论分布式系统从微服务走向智能体式 AI 架构的转变。过去微服务是把系统功能拆成小服务，各自负责一块；智能体式架构则是把“做决定”这件事拆开，交给多个能自主判断的 AI 智能体。作者指出，这种变化会让可观测性（看清系统内部发生了什么）、可靠性和整体设计都变得更复杂，因此需要更新原有的架构模式和实践。文章由 Mallika Rao 撰写，但目前只有摘要，具体方案和落地效果原文没有说明。
提供的材料未提及具体可用工具。
英国数字健康公司 Numan 做了一个叫 Nu 的 AI 健康教练，帮患者管理体重、激素和性健康等长期问题。难点在于：它只能做生活方式指导，不能越线变成诊断、开药或临床决策，这在医疗监管下是硬边界。团队原来用固定问答对和预设多轮脚本做评测，但教练是对话而不是答题，脚本也无法回应 AI 实际说了什么，导致误判。现在他们把每次评测都跑在生产同一个 LangGraph 图上，按类别分别打分，用模拟对话检验行为，并让安全探针直接卡住发布。对读者来说，这说明做受监管领域的 AI 产品时，评测标准本身比模型和流程更关键。
AWS 发布了一个叫 Well-Architected Agent 的 AI 助手预览版，用来检查用户的云环境是否符合 AWS 架构最佳实践。以前做这类架构审查往往要人工对照清单逐项排查，耗时且容易漏项；现在这个 Agent 会从成本、安全、性能、可靠性四个方面给出按优先级排序的改进建议，还能告诉你具体怎么修，并在部署前先审查基础设施即代码。对使用 AWS 的团队来说，相当于多了一个自动化的架构顾问，帮助更早发现问题、减少返工。目前它只是预览版，尚未正式开放，具体可用范围和收费方式原文未说明。
这篇文章讲的是 AI Agent 和 Kubernetes 运维工具各自该干什么。Kubernetes 一直靠“控制器”这类自动程序盯着集群状态、按规则把实际状态拉回目标状态，而现在的大模型 Agent 擅长的是调查问题、收集信息、给出建议，但让它直接改集群并不可靠。文章以开源项目 kagent 为例，提出一种分工方式：Agent 只负责观察、诊断和提出具体改动方案，真正执行仍交给 Kubernetes 控制器和策略系统，改动前还要人工或策略审批，改完再验证效果。文中用 Karpenter 扩容和 Argo CD 升级 Helm chart 两个例子说明好处：团队能更快找到问题原因、拿到风险说明清楚的窄范围补丁，同时集群的稳定性仍由原有确定性逻辑保证。kagent 是 CNCF Sandbox 项目，文中未说明其生产可用程度；KubeCon 相关会议信息与工具能力无关。
以色列初创公司 Uvi 本周三结束隐身模式，获得 750 万美元种子轮融资。它要解决的问题是：企业里用前沿大模型搭建的 AI Agent 每次回答前，都要重新翻 Slack、Jira、GitHub 等系统拼凑背景信息，导致成本虚高。Uvi 的做法是把公司已有的决策、对话、代码和流程集中整理成一个“记忆库”，让 Agent 一步拿到所需的最小正确上下文，而不是每次重做侦探工作。内部测试（未经独立验证）显示，同样的模型和问题下，接 Uvi 的 Agent 比直接连六个企业系统的 Agent 便宜约 8 倍、快 1 倍以上，单次回答成本从 0.75—1.41 美元降到 0.10—0.16 美元。对读者来说，这意味着未来换模型时不必让 Agent 重新学习公司背景，但实际效果仍待第三方验证，集成工具的范围也还没有完全公开。
Andrew Martin 做了一场演讲，主题是 AI 安全其实和 Kubernetes 安全密不可分。他谈到，AI 带来的新风险包括：智能体的行为不再完全可预测、GPU 供应链可能被做手脚、多个任务共用同一批算力会带来隐患。针对这些问题，他给出了一些实际防守办法，比如在提示词入口设置防火墙、给智能体分配独立身份。对在生产环境跑云原生 AI 应用的人来说，这些内容有助于判断该从哪些环节加固安全。
提供的材料未提及具体可用工具。
Cognition 推出的自主软件工程师 Devin 现在可以把能力延伸到线上事故处理上（即 Devin Oncall），它不再只是写代码，而是能调查生产问题、修改代码并提交合并请求。但 AI 代理要排查事故，不能只看源码，还得知道线上哪里出问题、改了什么、修复是否有效；过去它要自己到多个数据源里翻日志和指标，费时又容易出错。这次 Dynatrace 作为 Devin Oncall 的发布合作伙伴，把生产环境的运行时信息（问题、根因、日志、指标、链路、部署事件和安全发现）通过 MCP 服务器和技能插件接给 Devin，让它在同一个工作流里就能定位并验证修复。对使用 Devin 的团队来说，这意味着从收到告警到排查、修复、验证有可能在一个会话里完成，但目前仍需配置 Dynatrace 平台令牌和相应权限，实际可用范围取决于集成配置。
Snyk 发布了一个叫 VulnBump 的新测试基准，用来考察 AI 智能体能不能把项目里有漏洞的第三方依赖升级到安全版本。以前升级依赖很难：多数有漏洞的包是被间接引入的，约四分之一修复需要跨大版本，连小版本升级也常导致构建失败，所以虽然 94% 的漏洞都有已知修复版本，实际只有约 10% 被解决。VulnBump 用 307 个真实升级任务来考智能体，只有漏洞消失、项目仍能安装、构建并通过测试才算通过。结果显示：同一个 Claude Sonnet 5.5 模型，配上 Snyk 数据后通过率能提高约 18 个百分点，而 Snyk 专用智能体通过率达到 90.2%。对开发者的用处是：想安全修漏洞，光靠通用 AI 不够，还要有准确的升级建议和扫描验证。
有人在 BrowseComp-Plus 测试上做了个对比：把正确答案直接交给 GPT-4.1，它答对 93.49%；换成让同一个模型自己用 BM25 搜索找证据，答对率掉到 14.58%。这说明模型本身够聪明，但检索环节一旦拉胯，后面再强的推理也救不回来。文章还提醒，一个任务可能几分钟内发起成百上千次搜索，并且后续步骤依赖前面的结果，早期搜错会让整条链路跑偏。对做 Agent 的团队来说，先检查喂给模型的东西对不对，比急着换模型更划算。
这篇文章讨论的是：AI 让写代码变快了，一个过去要花几小时的任务，现在智能体几分钟就能给出初版代码，还能改仓库、重构服务、写测试、提 PR。问题是代码产出变多之后，团队反而更难确信这些代码能不能安全上线——编译通过、测试过了，也可能违反架构约定、引入安全漏洞或重复功能。作者提出把“代码信任”设计进交付流程，用一个公式：明确意图 × 护栏 × 独立验证 × 证据，四者缺一不可。对读者的用处是：理解为什么光靠人工逐行审查跟不上智能体的速度，以及可以从哪些环节入手让自动化产出更可控。原文是观点性文章，没有给出具体工具或产品。
提供的材料未提及具体可用工具。
有人测试了让 AI 客服代理处理退款等任务，发现如果给它的权限太宽，它即使发现交易根本没扣款也会照样退款，因为模型本身判断错了；而如果干脆不给它退款这个权限，这类错误就会被卡在执行层，跟模型好坏无关。作者搭了一套模拟企业 API 环境，比较一次性给全部权限、按角色给权限、按任务临时给权限、按需逐项申请权限四种做法，跑了 160 次。结果是按任务临时给权限最划算：完成率依然满分，但它手上同时活着的权限只有全量授予的十五分之一，出错时能波及的范围大幅缩小，代价几乎可以忽略。对企业的意义是：光靠改模型或系统提示词挡不住错误，把权限收窄才是最经得起降本和换模型折腾的护栏。文章没有说明这套方案在真实生产系统中的落地情况。
这是 Brendan O'Leary 的一场演讲，他基于 40 万亿 token 的使用数据，谈开发者实际是怎么采用 AI Agent 的。他的核心观点是：真正决定 AI 能不能落地的，不是模型跑分多高，而是用户是否建立起了信任。他提出 AI 采用分为四个台阶，并分析了上下文构建、多模型路由和反馈回路这几个容易出问题的环节，帮工程负责人把 Agent 工作流真正用起来。演讲标题提到 25 万亿，摘要里数据则是 40 万亿，原文未说明两者关系。
提供的材料未提及具体可用工具。
LangChain 团队基于 LangSmith 平台的经验，整理了 Agent 评测的常见问题。传统软件测试靠精确匹配，但 Agent 每次输出会变、正确答案不止一个、执行路径还可能绕弯，所以需要评测来打分。文章建议先从一条关心的行为入手，用真实 trace 建 10 到 20 条小数据集跑个基线，上线前用离线评测、上线后用在线评测，并优先用代码评测器、其次 LLM 评委、再用人工复核；多步 Agent 要评整条线程和最终状态。文中还提到 Terminal-Bench 这类基准和 Harbor 工具。
LangChain 在纽约和伦敦的 Interrupt 活动上集中发布了一批新功能，主要围绕让企业“拥有自己的智能”——也就是自己掌控模型、运行框架和业务上下文。过去团队做 AI 智能体时，调试、评测和上线往往靠零散工具，出了问题很难定位，也很难持续改进；这次的新版本把搜索、监控、轨迹查看、微调和托管智能体等能力整合进 LangSmith 和 LangChain。比如 AI 搜索可以用自然语言问“用户是否不耐烦”，自动找相关对话；Engine v2 能在上线前用红队测试发现问题并自验证修复；Managed Deep Agents v0.9 支持有记忆、会用工具、按计划执行任务的智能体。另有一些线上活动和社区聚会，部分内容需注册参加，具体发布状态与可用范围原文未逐一说明。
IDC与联想的一项联合研究发现，88%的AI概念验证项目最终没能进入实际生产环境，主要原因是目标不清晰、数据没准备好，以及公司内部缺少智能体AI方面的专业人才。问题出在“谁建谁不管”：负责设计和部署AI智能体的团队（往往是外部合作伙伴）不负责日常运行，而运营团队只熟悉演示环境，一上手真实业务就容易出错，严重时甚至引发连锁故障。解决办法是把每个智能体当成独立服务来管理：给它单独的权限和短期密钥、记录每一步操作、设置超时和失败重试，迁移平台时先用完整数据集逐项验证。对读者来说，这意味着部署AI智能体不能只看演示效果，缺少工程护栏的项目很难真正落地创造价值。
提供的材料未提及具体可用工具。
Google 在 Antigravity SDK 中新增了对本地模型的支持，开发者可以把智能体工作流直接跑在自己的电脑上，不再必须调用云端模型。以前这类工作流通常依赖云端，代码和数据要发出去，还受网络和推理费用限制。现在开发者能自己掌控数据隐私、推理成本、网络依赖和算力分配，同时仍可按需混用云端模型处理更复杂的任务。对开发者来说，写智能体时更省钱、更私密，弱网环境下也能跑。文中未说明具体支持哪些本地模型、开放时间或可用范围。
LangChain 开源了名为 Deep Agents 的智能体框架，用来解决长时间运行的智能体越跑越不准的问题。原因是任务越久，对话记录、工具返回结果和文件越堆越多，超出模型能承载的上下文窗口，准确率就会下降，这叫“上下文腐化”。它的做法是不删除信息，而是把大块工具结果和超长用户消息转存成文件、只给模型看一小段预览，快满时把旧对话压缩成摘要，任务技巧只在需要时加载，噪音大的工作交给子智能体另开窗口处理，学到的东西存成文件带到下次对话。这样模型每次只带真正需要的内容，需要细节时再回头查文件；由于记忆是存在你自己控制的存储里的普通文件，换模型或供应商也不受影响。文章还以每周竞品分析智能体为例演示这些方法，并通过中间件机制接入智能体运行循环。