Sluke的夹生饭

欲生还熟

对严肃落地的 Agent 系统而言，从 ad‑hoc agent → 标准化能力 → 按需组合的 just‑in‑time 微应用 / 界面，已经成为主流架构演进路线之一。

一、基本概念的阐述

1.1 ad‑hoc（临时型 Agent / 集成）

“ad‑hoc agents / ad‑hoc 集成”大致有几个典型特征：

  • 为某个具体任务/业务线 临时拼出来 的 Agent 或集成：

    • 手写 prompt + 若干工具调用
    • 写死调用某个 API、某个内部服务

  • 没有统一的身份、权限、审计和治理：

    • 谁能调？调了什么？改了什么？很难在全局追踪
    • 各团队各写各的，慢慢变成一堆“影子 IT”

  • 很难复用和扩展：

    • 要换一个流程，就得“再造一个 Agent”
    • API 变动、权限策略调整时，维护成本极高

可以把它理解为：“脚本时代的 Agent”——能跑，但不成体系。

1.2 just‑in‑time app / on‑demand app / ephemeral UI

“just‑in‑time app”可以抽象成三个核心特征：

1.2.1. 按需生成（on‑demand / just‑in‑time）

  • 用户或上层 orchestrator 给出一个意图（intent），系统临时组合：

    • 若干 Agent 能力
    • 若干数据源
    • 若干 UI 组件
  • 生成一个“微应用”/界面，服务于当下这一次任务

1.2.2. 生命周期短（临时性 / ephemeral）

  • 任务结束 → UI 消失、Agent 进程释放、临时身份和权限被回收
  • Medium 等文章把这类界面称为 “Ephemeral UI（短暂 UI）”：
    不是预先设计好的页面，而是由 Agent 在运行时为当前任务“现搭一个小工具”

1.2.3. 配合 JIT 身份 / 权限 / 资源

  • 安全和身份管理文章不断强调：对 Agent 应用，要从 ad‑hoc 访问转向 Just‑in‑Time 权限和身份：

    • 调用某个系统之前临时发一个短期凭证（token）
    • 权限严格限定在本次任务、本次调用
    • 用完即吊销，以降低横向移动和越权风险

所以，“just‑in‑time app”在 Agent 世界里并不仅仅是“即时写代码生成一个 App”，更像是：

在某个具体意图触发时，系统自动、临时性地把合适的 Agent 能力 + 数据 + UI 拼成一个一次性的“小应用”，并配套临时身份/权限。

二、为什么说“从 ad‑hoc → just‑in‑time app”是主方向之一？

从技术演进、经济与安全、标准生态三个角度看。

2.1 技术演进：从单 Agent 到“按需组装的能力网络”

比较有代表性的阶段划分（简化自多篇趋势/架构文章）：

2.1.1 Phase 1：Agentic Assistants（2024–2025）

  • 主要是单个 Agent + 若干工具（通过 MCP 之类协议）完成一个相对固定的任务

  • 形态往往接近 ad‑hoc：

    • 一个“旅行 Agent”、一个“代码 Agent”、一个“客服 Agent”，各自有自己的工具集和逻辑

2.1.2 Phase 2：Agentic Intranets（2025–2026）

  • 出现 Agent‑to‑Agent 协议（A2A），再加上 MCP 这类标准化工具协议，企业内部开始构建：

    • 多 Agent 协作
    • 动态路由和编排

  • 这时候，“应用”不再是预定义好的，而是：

    • 根据任务临时选哪些 Agent 加入“团队”
    • 临时暴露哪些 UI 片段，构成一个一次性“应用”界面

2.1.3 Phase 3：Internet of Agents（2027+，愿景阶段，仅是推测如此）

  • 可以跨组织、跨云地按意图 自动发现、组合 Agent

  • “应用”的概念进一步变弱，变成：

    • 用户给出一个高层意图
    • 系统在背后拼出一组 Agent 协作流程
    • 在本地浏览器/桌面/设备上生成必要的暂态 UI（just‑in‑time app），用完即弃

“从 ad‑hoc 升级到 just‑in‑time app”，本质就是从 Phase 1 的“一个个独立 Agent”向 Phase 2–3 的“按需组合的能力网络 + 暂态微应用”过渡——这在当前的路线图里，确实属于核心趋势而不是边角方向。

2.2 经济与工程现实：为什么 ad‑hoc 走不远，而 JIT 更有生命力？

ad‑hoc 模式的问题：

  • 每个 Agent 都是小项目：

    • 新需求 = 新 Agent
    • 跨部门协作 = 再堆一个 Agent

  • 维护地狱：

    • API 改一处，要改一堆 prompt/脚本
    • 安全策略、审计要求一变，所有 ad‑hoc Agent 都得翻修

  • 在安全和合规部门眼里是“黑盒风险源”：

    • 权限怎么下发的不清楚
    • 哪个 Agent 在什么时候改了哪个系统，很难全局追踪

just‑in‑time app / on‑demand 模式的优势：

2.2.1 开发效率

  • 重复的是“能力”而不是“应用壳”：

    • 把“查订单”“更新合同”“走审批”等封装为标准化工具/Agent 能力
    • 具体长什么 UI、不同行业怎么拼，只在运行时按需组合
  • 有报告预测：在这种模式下，大量业务应用从“开发周期几个月”缩短到“几天甚至几小时”，特别是内部工具场景

2.2.2 运营与治理

  • 所有能力通过共同的协议层（如 MCP、A2A）暴露，便于集中治理：

    • 统一日志
    • 统一权限策略
    • 统一审计与回滚

2.2.3 安全：JIT 身份 & 权限是从 ad‑hoc 走向规模化的前提

  • 多篇安全和 IAM 文章明确指出：

    • 今天大量 Agent 身份管理是 ad‑hoc 的（临时 token、共享账号、写死的 API Key） → 不可接受

    • 推荐模式是：

      • Just‑in‑Time 生成 Agent 身份和凭证
      • 权限严格限定在当前任务/时间窗
      • 用完销毁

  • 而 JIT app/ephemeral UI 的模式，天然就适合配合 JIT 身份/权限：

    • 应用本身就是一次性的
    • 不需要长期持有高权限

2.2.3 标准生态：从 ad‑hoc 集成到“协议 + 组件化能力”

2025–2026 这一波，有几个“拐点式”的事件：

  • MCP（Model Context Protocol）
    规范了“模型如何安全、标准地调用外部工具与资源”，从早期“各家 ad‑hoc 地给 LLM 挂工具”转向一个统一的“工具协议层”。
  • A2A（Agent‑to‑Agent）协议
    明确提出“Agent 不再只是和人对话，而是必须彼此通信”，进而需要标准化的交互方式——而非 ad‑hoc 的 HTTP+JSON 拼接。
  • 两者都被捐给开源基金会做标准化，这表明业界已经不满足于 ad‑hoc 拼接 Agent，而是要把 Agent 本身变成一个个可注册、可发现、可组合的“能力节点”。

在这种生态下，业务“应用”很自然就演化为：某一时刻对能力网络的一个“临时切片”，即你说的 just‑in‑time app。

三、如果你在做 Agent 产品 / 架构，应该怎么顺势演进？

3.1 不要再“造一个完整 Agent App”，而是“暴露能力 + 编排层”

建议的设计重心：

  • 把每个 Agent 能做的事抽象成：

    • 能力声明（schema）
    • 输入 / 输出约束
    • 所需权限范围

  • 让一个上层 orchestrator / workflow 引擎，按用户意图 动态选择和组合这些能力：

    • 有点像“微服务 + API Gateway”，但这里是“多 Agent + Orchestrator”

3.2 接受“App 是一次性快照”的思维：以 task 为中心，而不是以 App 为中心

如果我们在做的是前端 / 交互层：

  • 把 UI 视为 短暂的任务界面（ephemeral UI），而不是长期稳定的 App：

    • “帮我生成一份合同比对视图”
    • “给我一个一次性的审批界面”
    • “帮我做一个临时的销售看板”

  • 让 Agent 在运行时生成这个界面的布局、字段、操作按钮：

    • 任务完成 → 界面销毁
    • 只保留数据与审计记录，而不是界面本身

这比去做一个“全功能 Agent App”更符合趋势，也更可扩展。

3.3 在安全/治理上，刻意从 ad‑hoc 转向 JIT

如果 Agent 在企业落地，这一步非常关键：

  • 禁止：

    • Agent 共用高权限长周期 token
    • 在代码/Prompt 里硬编码凭证

  • 推荐：

    • 为每个 Agent/每次任务申请短效凭证（JIT token）
    • 所有凭证/调用流通过统一的身份网关
    • 全量日志：谁触发 → 哪个 Agent → 以谁的身份 → 调了哪个系统 → 做了什么修改

3.4 思考一个“演进路线图”而不是一次性重构

对于已经有一堆 ad‑hoc Agent 的团队，可以这样分阶段演进：

  1. 梳理存量 ad‑hoc Agent：

    • 抽出其中可复用的“能力”（工具、API、流程片段）
    • 统一收口到类似 MCP 的工具层或自己的能力注册中心

  2. 搭建简单的 orchestrator / workflow 层：

    • 先从少数典型任务入手，让这些任务可以按需组合能力，而不是直连具体 Agent

  3. 引入 JIT 身份 & 审计：

    • 所有新建的流程一律走 JIT 模式
    • 逐步把老的 ad‑hoc 流程迁到新模式下

  4. 最后再考虑 UI 的 Ephemeral 化：

    • 先做“Agent‑中心”的 JIT 能力
    • 再做“用户界面”的 JIT（just‑in‑time apps / ephemeral UI）

四、总结：从“做一个 Agent”到“做一个 JIT 能力网络 + 临时应用层”

4.1 在以下领域，just‑in‑time 是主流路线：

  • 可规模化的企业落地
  • 安全与合规
  • 多 Agent 协作与动态编排

4.2 其他趋势：

  • 多 Agent 编排与“Agent 团队”
  • 从单大模型到多模型/小模型混用（cost/perf FinOps）
  • 强治理、强 observability 的 Agent 平台化
  • 行业垂直化（vertical agents）

标签：ai

你的评论
龟 界 悟 超