[agent] Multi-model Agents, why?

桃厂面试官：“Agent 不就是 LLM 挂几个插件？”，我反问：“Agent Loop、上下文工程、MCP，您管这叫挂插件？”

Part 1

工程视角：Agent Loop 的设计难点不在循环本身，而在于如何高效管理随迭代不断增长的上下文。上下文过长会导致关键信息被稀释、推理质量下降，这也正是 Context Engineering 要解决的核心问题。

在 LangChain、LlamaIndex、Spring AI 等主流框架中，Agent Loop 均有封装实现，可通过监控迭代次数、Token 消耗等指标诊断 Agent 性能瓶颈。

ReAct Loop: Thought → Action → Observation → 再思考

Agent Loop: 读取上下文→ LLM 决策→ 调用工具→ 获取结果→ 写回上下文→ 下一轮决策

1. LLM Call（模型调用）：底层 API 管理，负责抹平各大厂商 LLM 的接口差异，处理流式输出、Token 截断、重试机制等基础能力。例如，支持 OpenAI、Anthropic 或 Hugging Face 模型的统一调用，确保兼容性。
2. Tools Call（工具调用）：解决 LLM 如何与外部世界交互的问题。涵盖 Function Calling、MCP（Model Context Protocol）、Skills 等机制。主流应用包括本地文件读写、网页搜索、代码沙箱执行、第三方 API 触发（如邮件发送或数据库查询）。
   • 在 MCP 之前，大家已经有 function calling 了。详情见下面的PDF Reader的例子。
3. Context Engineering（上下文工程）：管理传递给大模型的 Prompt 集合。
• 狭义：系统提示词的编排（如 Rules、角色的 Markdown 文档等）。
• 广义：动态记忆注入、用户会话状态管理、工具与 Skills 描述的动态组装。

• 也就是说：SIPDO 是一种 Context 更新算法。提供了一种在循环中增强context的思路。

 

[MCP]

首先要明确，这个系统需要哪些原子能力，以及哪些适合做成 MCP server 的能力。

• 可被多个 Agent/App 复用

• 边界清晰

• 输入输出可定义

• 权限边界独立

• 有独立生命周期

 

比较适合独立出来的是：

1. PDF Reader MCP Server

因为以后很多 agent 都会用到 PDF 能力。

原则：只负责“文档结构提取”，不负责业务语义终判，如下。

• • parse_pdf_text

  • extract_page_image （在实现时，要定义其输入输出）

  • extract_figures

  • extract_tables

  • get_page_region_snapshot

2. Traffic Knowledge MCP Server

因为这是领域知识服务，以后很多场景可复用。

3. Project Reference MCP Server

因为项目私有资料检索很常见。

4. CAD Symbol MCP Server

如果你们交通图/CAD 解释是独特能力，非常适合服务化。

 

说白了，就是做成类似container的模式再暴露rest api。仅此而已。

 

[SKILLS]

没有 Skills 时的 Agent 世界，过程中的“细节不太可控”

出现一个需求：固定“做事套路”。

如果让llm每次都planning，可能planning results都不会太一样。

于是出现一个想法：

把这些流程预先写好，让 Agent 直接调用。例如以下流程说明：

Goal:
Review a pull request and identify issues.

Steps:
1 Read PR description
2 Fetch code diff
3 Identify potential bugs
4 Check test coverage
5 Produce structured review comments

Tools:
- github.get_pr
- github.get_diff

也就是一套行业通用的术语定义：Skill = 任务说明 + 工具组合 + 执行套路 

工程代码里可以如下这样组织文件：

skills/
　　code_review/ （按需加载的最小单元）
　　　　skill.md
　　　　instructions.md
　　　　tools.yaml

 

[Context7]

Context7 = 把 LLM 需要的上下文拆成 7 类信息，并按结构管理。

这样做的原因是：
随着 Agent 系统变复杂，Prompt 已经不够用了，需要更系统的 Context Engineering。

例如：“解释第8页这个图。”

类型	含义
1 System Context	系统规则、角色	You are a traffic engineering assistant.
2 Task Context	当前任务	User wants explanation of figure on page 8
3 Conversation Context	历史对话	Earlier the user asked about pedestrian crossing
4 Memory Context	长期记忆	User project = special trial
5 Tool Context	工具能力	Tools available: - extract_page_image - lookup_traffic_term - search_reference_docs
6 Knowledge Context	外部知识	Transport guideline excerpt
7 Environment Context	当前状态	skills 是预定义规则的一套格式标准 context7 是每轮上下文遵循的格式标准Current page image

 

skills 是预定义规则的一套格式标准，静态的。
context7 是每轮上下文遵循的格式标准，动态的。

所以：

• Skill 很少变化
• Context 每一轮都会变化

Agent 每一轮推理时发生什么？一轮推理其实是： 

1 选择 Skill
2 构造 Context
3 调用 LLM
4 得到 Action
5 调用 Tool
6 更新 Context
7 下一轮

 

 

LLM Agents MOOC | UC Berkeley CS294-196 Fa24 | Agentic AI Frameworks/AutoGen & Multimodal Assistant

 为何有些AI 产品会有应用场景倾向性？因为它们本质上是：

• Science Agents
• Web Agents
• Software Agents

Multi-Agent（多个AI协作）如何比单个LLM更强?

未来AI不是一个模型，而是一群模型组成的系统。

 

Jeff: 可能是2024的“老课”，在此大概了解下相关概念和背景即可。

 

How to build a Multimodal Knowledge Assistant?

可以直接记成这张图：

LlamaParse
↓
把复杂文档解析好

↓

LlamaIndex
↓ 
拿解析后的数据做索引、检索、RAG、Agent、Workflow

↓

LlamaDeploy
↓ 
把这些 workflow / agent 系统部署成生产可运行的微服务

也就是说：

• LlamaParse 解决“原始文档怎么吃进去”

• LlamaIndex 解决“吃进去以后怎么让 LLM 真正用起来”

• LlamaDeploy 解决“做好以后怎么上线跑起来”