June 26, 2026 · 10:13 AM

AI Agent 生态速报 | 6月25日晚间：工单、客服和运行底座同步补位

本期梳理 6 月 25 日晚间到 26 日早间的 Agent 生态动态：Copilot 进入 Jira 与企业插件治理，Salesforce 把客服 Agent 包装成按结果付费产品，Lambda 与 Solo 则把实验记忆和部署抽象推向生产基础设施。

Agent 生态周报 @chinamusk

Research Brief

北京时间 6 月 25 日晚间到 26 日早间，Agent 生态的关键词不是「更会聊天」，而是「谁来管它、怎么计费、跑在哪里、怎么记住实验结果」。这几条更新放在一起看，Agent 正从应用功能变成企业软件里的可治理执行单元。

快读：这 5 条信号值得先扫一遍

Salesforce 发布 Agentforce Help Agent，主打预打包客服 Agent、跨 voice/web/portal/messaging 部署，以及「只在端到端自主解决问题时收费」的 pay-per-resolution 定价；官方披露它将在 2026 年 7 月 GA，定价也在 7 月可用。1
GitHub Copilot for Jira 从 3 月公测走到 GA，新能力包括 Jira 工单内实时查看 coding agent 进度、在 draft PR 之后继续从 Jira chat panel 追发指令，以及保留在同一个 PR 上继续工作。2
GitHub Copilot code review 改用 Copilot CLI 和 SDK 内置的 grep、rg、glob、view 文件探索工具。GitHub 称这让 code review 成本约降 20%，同时维持相同审查质量。3
GitHub 企业托管设置新增 strictKnownMarketplaces 公测，企业可以限制 Copilot CLI 和 VS Code 里用户只能安装来自显式定义 marketplace 的插件。4
Lambda 把 Claude Code 接到实验追踪 API，展示它在 CVPR 2026 期间让 Gemma 4 玩类 Tetris 游戏：468 次实验、90 个 idea 分支、约 810 次 API 调用，核心工具 the_lab.api 已开源。5

产品层：Agent 开始嵌进工单和客服结算

Salesforce 这次的重点不是「又有一个客服机器人」。Help Agent 的产品包装有两个变化：第一，它把知识接入、动作库、跨渠道部署和测试预览做成预设路径；第二，定价从席位、对话量或 token 消耗，转向按自主解决结果计费。官方还给了自己的运行基准：Agentforce 在 help.salesforce.com 已处理 430 万次咨询，解决率为 70%。1

这会改变采购问题。过去买客服 Agent，团队常问「调用成本会不会失控」。按解决结果计费后，更该问「什么算一次有效解决」「负反馈、人工升级、重复工单怎么归因」「知识库脏数据导致误解时谁承担成本」。对产品团队来说，Help Agent 值得跟踪的不是界面，而是计费口径和验收标准。

GitHub Copilot for Jira 的 GA 也指向同一个方向：Agent 不再只待在 IDE。它进入 issue 系统，进度直接回流到 Jira；人类在 draft PR 生成后，还能继续在 Jira 里给后续指令，让 agent 继续改同一个 PR。2 这更像把「需求工单 → 代码变更 → 评审」串成一条受控工作流，而不是把 coding agent 当作单次代码生成器。

控制面：成本、插件和上下文访问一起收口

GitHub 的两条企业更新可以放在一起看。code review 这边，Copilot 从自定义文件探索工具迁到 CLI/SDK 共享工具，成本约降 20%；Medium analysis depth 预览还新增 PR overview comment 里的 Medium 标识和组织级默认审查深度。3

插件治理这边，strictKnownMarketplaces 把「用户能给 Copilot CLI / VS Code 装哪些插件」变成企业托管设置。GitHub 明确把它描述成 tool execution 之前的 client governance：先减少未受信插件进入执行路径，再谈 Agent 能做什么。4

这说明企业 Agent 的治理边界正在前移。以前重点是「模型输出是否安全」；现在更实际的问题是「模型能看哪些文件、能调用哪些工具、能安装哪些插件、默认用多深的审查力度」。这类控制项不显眼，但它们决定了 Agent 能不能进入组织级默认流程。

基础设施层：Agent 需要自己的实验记忆和部署抽象

Lambda 的案例很适合作为反面提醒：Agent 会跑实验，但没有结构化记忆时，它会重复试错或追着偶然高分跑。the_lab.api 给 Agent 的不是人看的 dashboard，而是可查询的实验、排行榜、idea 分支和历史记录。Claude Code 在 demo 中查询 leaderboard、开新分支、跑实验、总结 idea，再重复这个循环。5

更关键的是沙箱边界。Lambda 锁住 game engine、client 和 scoring harness，只允许 Agent 调 prompt、inference 参数、vLLM 启动参数、采样参数和是否启用多模态等变量。否则，一个足够聪明的 Agent 很可能直接改游戏逻辑来「拿高分」。5 这对评测平台、自动调参和研究助理都有参考价值：要测模型能力，就得先把 Agent 的作弊路径堵住。

Solo.io 的 kagent/agent-substrate 则从部署单元切入。文章先承认「每个 Agent 一个 Pod、Service、ServiceAccount」能解决隔离、身份、网络策略和可观测性问题；但 Agent 往往是短生命周期、突发执行、会创建子 Agent、可能等待人工批准的对象，长期给每个 Agent 保持一个 Pod 会浪费资源。6

agent-substrate 的解法是把 Kubernetes 继续作为 Pod、Service、网络、存储和计算层，另起一层控制面来调度逻辑上的 Actor。WorkerPool 像 NodePool，Worker 像 Node，ActorTemplate 像 PodTemplate；Kubernetes 看到的是固定数量的执行 Pods，agent-substrate 管的是更多轻量 Actor。6 这条线还早，但问题问得很准：Agent 的身份、配额、审计和生命周期，未必应该绑死在底层 Pod 上。