Agent

文章发布时间:

最后更新时间:

https://arxiv.org/abs/2508.01186 A Survey on Agent Workflow

三层架构： 典型的系统包括 UI/UX 层（用户交互）、工作流管理层（任务调度，流程控制）和 智能体协作层（多智能体通信与授权）

角色分工： 常见的角色包括规划者（Planner）、执行者（Executor）、解析者（Parser）、评论者（Critic）和内存管理器 。

工作流模式： - 链式（Chain）： 顺序执行 。 - 并行（Parallelization）： 独立任务同步处理 。 - 路由（Routing）： 根据输入特征调度任务 。 - 编排者-工作者（Orchestrator-Workers）： 中心化调度 。 - 评估者-优化者（Evaluator-Optimizer）： 通过反馈循环实现自我改进 。

各个框架的差异 - 规划 (Planning)： 系统是否具备独立规划任务流程的能力，而非仅仅执行固定步骤 。 - 工具使用 (Tool Use)： 智能体是否能调用外部工具（如 API、计算器、搜索引擎）。 - 多智能体支持 (Multi-agent)： 系统是否支持多个智能体协同工作 。 - 内存机制 (Memory)： 是否包含显式的内存机制，用于管理多轮对话的状态和历史信息 。 - 图形界面交互 (GUI)： 智能体是否能通过模拟人类操作（如点击、输入）与图形界面交互，而不仅仅是调用后端 API 。 - API 交互： 是否通过结构化 API（如 Function Calling）与外部系统交互 。 - 自我反思 (Self-Reflection)： 智能体是否具备自我评估或反思能力，通常表现为循环迭代过程 。 - 自定义工具 (Custom Tools)： 框架是否允许用户定义并集成新工具 。 - 智能体角色 (Agent Roles)： 框架是否支持定义特定角色的智能体（如 Planner, Executor, Critic） - 表示法 (Representation)： 任务计划或工作流的形式化描述方式，如 DAG（有向无环图）、状态机、流程图或脚本 - 语言： 使用 Python、YAML、JSON 或特定领域语言（DSL）来定义工作流 。

我们现在讨论的大部分高级应用，实际上都是基于工作流的多智能体系统（Workflow-based Multi-Agent System）

Agent=LLM+Prompt+Tool Use+Memory+Planning

ReAct

伪代码逻辑

thought - action - observation 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
system_prompt = """
你是一个具备推理能力的助手。你可以使用以下工具：
- Search[query]: 在联网搜索引擎中查找信息。
- Calculator[expression]: 计算数学表达式。

请按以下格式回答问题：
Thought: 你对当前问题的思考。
Action: 你要执行的动作（只能是 Search 或 Calculator）。
Observation: 动作执行后的结果（我会提供给你）。
... (重复上述步骤)
Final Answer: 最终得出的答案。

现在开始：
问题：奥本海默的出生年份乘以 2 是多少？"""


question = "奥本海默的出生年份乘以 2 是多少？"
history = system_prompt + question

while True:
    # 1. 让模型生成输出 (Thought + Action)
    response = llm.generate(history) 
    print(response)

    if "Final Answer:" in response:
        break
    
    # 2. 解析 Action (例如通过正则提取 Search[1904])
    action_type, action_input = parse_action(response)
    
    # 3. 执行工具并获取结果 (Observation)
    observation = execute_tool(action_type, action_input)
    
    # 4. 将观察结果拼接回历史，继续循环
    history += f"\nObservation: {observation}\n"

ReWOO

Reasoning Without Observation

模型一次性生成一份完整的执行蓝图。它会预设好每一个步骤，并使用占位符（如 #E1, #E2）来代表尚未获取的结果。

  • 例子：
    • Step 1: Search[奥本海默出生年份] (#E1)
    • Step 2: Search[爱因斯坦出生年份] (#E2)
    • Step 3: Calculator[#E1 + #E2] (#E3)

然后我们解析之后，用langgraph写一个DAG，然后执行。 提高性能（并行），减少token

autogen

它的核心理念是 Multi-Agent Conversation（多智能体对话）。它让多个具有不同分工的 AI 角色（Agent）通过互相聊天、协作、甚至互相纠错来完成任务。

  • 代码执行器
  • 设计不同的开会方式
  • 控制力低，自主性高

ChatDev 与 Meta-GPT

而是专为软件开发（Software Engineering）量身定制的“虚拟工厂”。 - Product Manager: 只能产出 PRD.md。 - Architect: 只能根据 PRD 产出 System_Design.json。 - Engineer: 必须参考上述两个文件才能写 code.py。

Langgraph

RAG

文档切分（500字），embedding 提问 embedding，查找文档块，加入prompt中 长期记忆：使用一个轻量级 LLM 实时监控对话，如果发现重要信息（如“用户说他住在上海”或“用户偏好 Python 语言”），LLM 会将其总结为一条简短的事实，将这条“事实”通过 Embedding 模型转为向量，存入用户的专属向量分区。

openai/智谱调api进行embedding，0.5元/百万token。或BGE，M3E开源模型，吃一点硬件。 postgres + pgvector插件，计算余弦距离 ORDER BY embedding <=> '[0.012, 0.023, ...]' LIMIT 5。索引提高速度，HNSW分层网络，都是动态的，从顶层开始查。IVFFlat分成N个簇，数据快速改变后需要训练。

CLIP算法搜图：CLIP 将图片和文字都映射到同一个向量空间中

AI工具探索

发现并不是能用就是，每个ai工具都有自己的边界和擅长的部分。

调研（manus）-> design（claude？？）-> 拆解任务为一个个代码模块（OpenSpec）(Spec-Driven AI Development 规范文档)

gemini

代码能力不行 3 flash不知道“Claude Code 的 Plan 模式 是什么”，感觉对最新的，容易混淆的名词不是很懂 Gemini 3.1 Pro 搭前端？（Google Gemini Studio是否能“看到”预览页面）

Manus

适合调研和控制浏览器等通用的东西，强项应该是浏览器控制（爬虫）？

openspec

面向存量项目（brownfield），而不只是新项目（greenfield）

Skill

渐进式披露（按需加载） 结构：元数据层（名称和描述，是一开始就加入上下文的），指令层，资源层 和mcp区别是这是针对某一任务专门agent用的逻辑

Superpowers

软件工程师的sop 脑暴 - 计划&写测试 - 子智能体执行 - 复现&debug

multiagent

主要解决的问题是分割上下文和专业性（只用读取一部分skill）

上下文压缩

窗口大小：100万？25年可能20万 滑动窗口，摘要，

≡