大模型Agent架构演进：从临时拼接到按需组合的微应用之路（程序员必收藏）

文章阐述了Agent系统架构从ad-hoc临时型Agent向标准化能力再向按需组合的just-in-time微应用/界面的主流演进路线。这种演进解决了ad-hoc模式在治理、复用、安全方面的问题，通过标准化协议(MCP、A2A)和JIT身份权限管理，实现开发效率提升、运营治理优化和安全合规增强。企业应转向"能力网络+临时应用层"架构思维，分阶段实施转型。

对严肃落地的 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.1Phase 1：Agentic Assistants（2024–2025）

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

○形态往往接近 ad‑hoc：

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

2.1.2Phase 2：Agentic Intranets（2025–2026）

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

▪多 Agent 协作

▪动态路由和编排

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

▪根据任务临时选哪些 Agent 加入“团队”

▪临时暴露哪些 UI 片段，构成一个一次性“应用”界面

2.1.3Phase 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）