AI Agent Application
AI Agent 应用是以 LLM 为推理核心、以工具调用为执行手段、以状态管理为控制基础的交互式智能应用。它不是聊天机器人的简单升级，而是一种全新的软件架构范式。
#type / concept
#status / evergreen
#tech / ai
#tech / architecture
[!info] related notes
- 所属 MOC: AI Agent Application MOC, Agent MOC
- 上游概念: Agent, Augmented LLM
- 并列概念: Agentic Application Stack
- 下游概念: Agent Runtime, Tool Calling 工程化, Context Engineering
AI Agent Application
一句话定义
AI Agent Application 是以 LLM 为推理核心、以工具调用为执行手段、以状态管理为控制基础的交互式智能应用。它和传统应用的根本区别在于：控制流由模型动态决定，而不是由代码预先编写。
它解决什么问题
传统应用的逻辑是确定性的：用户点按钮 → 触发预定义的函数 → 返回结果。但很多真实任务无法用确定性逻辑穷举：
- 用户用自然语言描述复杂需求（“帮我分析这个数据集的趋势”）
- 任务需要多步推理和动态决策（“先搜索相关信息，再整理成报告”）
- 执行路径取决于中间结果（“如果检索到的内容不够，换个关键词再搜”）
AI Agent Application 让 LLM 成为”决策者”，由它决定调用哪些工具、以什么顺序执行、何时结束。
核心原理
与传统应用的本质区别
传统应用:
用户输入 → 预定义逻辑 → 输出
(控制流在代码中)
AI Agent 应用:
用户输入 → LLM 推理 → 动态选择工具 → 执行 → 结果回传 LLM → 继续推理或输出
(控制流由模型决定)核心组成
一个 AI Agent Application 至少包含：
| 组件 | 职责 | 例子 |
|---|---|---|
| LLM | 推理与决策 | GPT-4, Claude |
| Tools | 执行具体动作 | 搜索、数据库查询、API 调用 |
| Memory | 维护上下文和状态 | 对话历史、用户画像、任务状态 |
| Runtime | 管理执行循环 | 超时、重试、并发、权限控制 |
| Interface | 用户交互层 | Chat UI、审批界面、结果展示 |
Anthropic 的分类
Anthropic 在 “Building Effective Agents” 中区分了两类系统：
- Workflow: 通过预定义代码路径编排 LLM 和工具（确定性控制流）
- Agent: LLM 动态决定自己的执行流程（模型控制流）
两者不是非此即彼，而是可以组合。大多数生产系统是 workflow 的确定性骨架 + agent 的动态决策节点。
在 React + Go + Python AI Service 架构中的位置
┌─────────────────────────────────────────────┐
│ React 前端 │
│ - Chat UI (消息输入/输出) │
│ - Tool Call UI (工具调用状态展示) │
│ - Human Approval UI (审批界面) │
│ - Artifact Viewer (结果/文件查看) │
│ - SSE Client (流式事件消费) │
└──────────────────┬──────────────────────────┘
│ HTTP / SSE
▼
┌─────────────────────────────────────────────┐
│ Go 后端 (BFF 层) │
│ - Session & Message 管理 │
│ - Context Builder (上下文组装) │
│ - SSE Gateway (流式事件转发) │
│ - Auth & RBAC (权限控制) │
│ - Audit Log (审计日志) │
│ - Event Contract (事件协议) │
└──────────────────┬──────────────────────────┘
│ gRPC / HTTP + SSE
▼
┌─────────────────────────────────────────────┐
│ Python AI Service (Agent 引擎) │
│ - Agent Runtime (执行循环) │
│ - Tool Registry & Executor │
│ - RAG Engine (检索增强生成) │
│ - Memory Manager (记忆管理) │
│ - LLM Provider Abstraction │
│ - Trace & Observability │
└─────────────────────────────────────────────┘典型工程实现
一次 Agent 调用的完整流程
1. 用户在 Chat UI 输入: "帮我查一下最近一周的销售数据，做个趋势分析"
2. React 前端发送 POST /api/chat/message
3. Go 后端:
a. 鉴权、创建 turn_id
b. ContextBuilder 组装上下文（历史消息 + 用户画像 + 工具列表）
c. 转发请求到 Python AI Service
d. 开始 SSE 流式转发
4. Python AI Service:
a. Agent Runtime 启动 Run
b. LLM 推理: 决定先调用 query_database 工具
c. Tool Executor 执行数据库查询
d. 结果回传 LLM
e. LLM 推理: 决定调用 create_chart 工具生成图表
f. Tool Executor 生成图表
g. LLM 生成最终文本回复
h. Run 完成
5. Go 后端通过 SSE 逐步转发事件到前端
6. React 前端渲染: 文本 + 图表 + 工具调用状态Agent Loop 伪代码
async def agent_loop(run: Run):
messages = build_context(run)
while not should_stop(run):
# 1. 调用 LLM
response = await llm.chat(messages, tools=registry.get_tools())
# 2. 检查是否有 tool_call
if response.has_tool_calls():
for tool_call in response.tool_calls:
# 3. 权限检查
if not permission_check(tool_call):
yield ErrorEvent("权限不足")
continue
# 4. 执行工具
result = await tool_executor.execute(tool_call)
# 5. 结果回传
messages.append(tool_call_message(tool_call, result))
yield ToolResultEvent(tool_call, result)
else:
# 6. 没有 tool_call，LLM 直接回复
yield TextDeltaEvent(response.text)
break
# 7. 检查停止条件
if run.step_count >= max_steps:
yield ErrorEvent("超过最大步数")
break常见设计模式
- 单 Agent 模式: 一个 LLM + 一组工具，适合简单任务
- Multi-Agent 模式: 多个 Agent 协作，每个负责一个子任务
- Orchestrator-Worker 模式: 一个编排者 Agent + 多个工作 Agent
- Evaluator-Optimizer 模式: 生成 Agent + 评估 Agent 的闭环
- Human-in-the-loop 模式: 关键节点引入人类审批
常见坑
- 把所有逻辑都交给 Agent: 不是所有任务都需要 Agent，确定性逻辑应该用代码
- 工具太多: 工具数量超过 20 个时，模型选择准确率下降
- 没有停止条件: Agent 可能无限循环，必须设置 max_steps
- 忽略错误处理: 工具执行失败时的降级策略
- 上下文爆炸: 不控制历史消息长度，导致 token 超限
和其他概念的关系
- vs Agent: Agent 是概念，AI Agent Application 是工程实现
- vs Agentic Workflow Patterns: Workflow 是其中一种编排模式
- vs Agent Runtime: Runtime 是 Application 的执行引擎层
- vs Context Engineering: Context Engineering 是 Application 的信息组装层
总结
AI Agent Application 的本质是让 LLM 成为应用的决策层，而传统代码负责执行层和控制层。理解这个架构，才能做好 Agent 的工程化。