Microsoft Foundry Toolkit 工具箱与 Agent Inspector 更新

摘要：Microsoft Community Hub 在 8 月 28 日总结了 Foundry Toolkit for VS Code 的四次发布：1.6.7、1.6.8、1.6.9 和 1.6.10。更新没有只增加一个“更聪明”的聊天入口，而是把创建 Agent、复用受治理工具、连接其他 Agent、隔离真实用户会话，以及定位一次运行的时间和工具证据，放进了同一条开发路径。对正在把 Agent 从演示推向团队服务的开发者，这个变化的重点是调试和治理终于有了具体入口，但 A2A 仍是预览能力，模型和权限配置也没有因此自动变得正确。

Foundry Toolkit 重新设计的 Create Agent 页面截图 — 图：Create Agent 页面把多种开发路径放在同一入口，减少从错误抽象开始搭项目的返工。来源：Microsoft Community Hub。

很多 Agent 项目的第一种浪费，不是模型回答慢，而是团队先选错了实现方式：有人需要代码框架，有人只要 Prompt Agent，有人要 Copilot 辅助编码。选错之后再迁移，工具连接、会话文件和调试方式都要重做。本文只分析这四个版本共同指向的一件事：Foundry Toolkit 如何把“建起来”之后的复用、隔离和观察补到工作流里。

这也解释了为什么普通的功能清单不够。一个 Agent 能调用工具，并不等于团队能知道它调用了哪个版本、以谁的身份调用、花了多少 token、失败发生在哪个参数。真正影响交付的，是这些信息是否能在开发者熟悉的 VS Code 环境里被复盘。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

具体发生了什么：四个版本把开发路径向后延伸

官方更新记录显示，1.6.9 的重新设计让 Create Agent 页面直接提供 Microsoft Agent Framework、Copilot SDK、LangGraph、Copilot-assisted coding、Agent Builder 和完整样例目录；同一版本还加入了 user-scoped Hosted Agent sessions，使 Responses 对话和 session files 按用户身份隔离。1.6.10 则加入 Prompt Agent toolboxes 和 A2A connections（preview）：工具箱可以集中管理工具、技能、版本、审批策略和嵌套工具，A2A 连接可以来自现有连接、Foundry 账户目录或自定义 HTTPS endpoint。

这组事实改变的是入口和资源的组织方式。以前把五个 MCP 工具分别塞进五个 Agent，往往会产生五份审批和版本配置；现在可以把它们作为一个可替换的工具箱资源。类似地，外部专业 Agent 不必藏在 prompt 文本里，而能作为连接挂在 Prompt Agent 上。不过“可管理”不等于“可信”：连接目标、工具权限和批准策略仍由团队负责。

一个完整场景：从选型到一次可审查的运行

假设团队要做一个内部工单分流 Agent。开发者先在 Create Agent 页面选合适的代码或 Agent Builder 路径，再把工单查询、知识库检索和通知动作放进集中工具箱。若需要专门的安全分类 Agent，可把兼容 A2A 的服务接入为连接，形成“主 Agent → 工具箱 → 专业 Agent”的组合。测试时为每名测试用户设置 user identity，让对话和 session files 不会混在同一个共享会话中。

交付前，开发者打开 Agent Inspector。官方说明的 Overview 同时提供 latency waterfall 和按顺序排列的 model、reasoning、tool activity 时间线；响应页脚显示模型、耗时、总 token 和时间戳，工具调用还可按 response run 展开 status、call ID、arguments 和 results。于是“回答不对”可以被拆成：检索工具返回为空、A2A 响应超时，还是模型在拿到正确结果后生成了错误判断。这样的证据链比重新读聊天气泡更适合写回归测试。

Foundry Agent Inspector 展示延迟瀑布和模型推理工具调用时间线 — 图：Inspector 把最终答案背后的时延、模型活动和工具参数展开，帮助定位具体失败点。来源：Microsoft Community Hub。

为什么这不是简单的工具增加：Agent 开始像一个可运营系统

工具箱、A2A 和 Inspector 分别解决复用、组合和观察，但组合起来才会改变开发逻辑。团队可以把工具版本和审批政策当成资源治理，把专业 Agent 当成可替换组件，再用运行证据衡量到底是哪一层拖慢了流程。对产品团队而言，这让“先做一个会回答的 Demo”转向“能解释一次请求如何完成”。

这种转向也带来一个现实收益：当 Agent 需要从实验走向多人使用时，用户身份和会话文件不再是隐藏的本地细节。每个用户的上下文边界可以进入测试设计，Inspector 的 token、时延和调用结果可以进入成本与质量评估。它没有保证质量，但让质量问题更容易被定位和复现。

Foundry Toolkit 中配置 Agent-to-Agent A2A 连接的截图 — 图：A2A 连接（预览）把外部 Agent 变成可以配置和复用的连接资源。来源：Microsoft Community Hub。

限制、权限与人需要接管的节点

首先，A2A 在官方文章中明确标为 preview，不能按稳定生产能力承诺 SLA 或兼容性。其次，工具箱只是集中管理 MCP-compatible endpoint，并不会替团队审核工具是否安全；审批策略、连接 endpoint、用户身份映射和模型选择仍需管理员和开发者共同确认。第三，官方还说明 GitHub Models 已因服务退役从 Model Catalog、playground、Agent Builder 和 evaluations 移除，引用它的保存工作流需要改选可用模型。

低风险试用可以从一个不含敏感数据的工单样本开始：固定工具箱版本和审批策略，给两个测试用户分别运行同一组请求，记录 Inspector 中的工具参数、失败率、总 token 和端到端时延，再故意切换一个工具版本观察回归。只有当这些证据能被团队复盘，再考虑接入外部 A2A Agent 或真实用户会话。人要在发布前确认身份隔离、网络出口、数据保留和升级回滚。

结论：先把运行证据补齐，再扩大 Agent 组合

Foundry Toolkit 8 月更新的价值，不是把 Agent 开发变成一键搭建，而是把“选型、复用、组合、隔离、检查”排列成一条可追踪的链路。对小型实验，最值得先试的是 Inspector 和 user-scoped session；对有多个工具或专业 Agent 的团队，再评估 toolbox 与 A2A。若团队还没有明确的权限、回滚和成本记录，仅仅增加连接数量只会把问题藏得更深。