Tallate

该吃吃该喝喝 啥事别往心里搁

human-in-loop是指在agent的循环执行中,让人能够介入,从而让自动化流程中可以使用人这个工具来实现输入密码、授予权限等操作。
实现human-in-loop主要取决于两个能力:

  1. 阻塞通知能力,原地阻塞,等待用户输入,用户输入将通过事件通知的方式来触发流程的继续执行,例如:LlamaIndex和ADK的实现
  2. 中断恢复能力,在关键执行节点保存执行上下文,让任务能恢复执行,例如:LangGraph的实现

LangGraph的实现模式

LangGraph 中的人机循环工作流建立在 checkpoint 系统之上,使用检查点保存每一步的图形状态,并在人工干预后恢复。

中断原语

中断时序图.png

Common Patterns(常见模式)

LangGraph中的人机循环实现提供了几种常见的模式,用于不同的应用场景:

1. 审批或拒绝模式(Approve or Reject)

Node中断执行流.png
用于需要人工审批的场景,比如内容审核、决策确认等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
def approval_node(state):
# 准备需要审批的内容
content_to_review = state["generated_content"]

# 中断等待人工审批
approval = interrupt({
"content": content_to_review,
"action": "approve_or_reject"
})

if approval == "approve":
return {"status": "approved", "content": content_to_review}
else:
return {"status": "rejected", "content": None}

2. 审查和编辑状态模式(Review and Edit State)

允许人工审查当前状态并进行编辑修改。

1
2
3
4
5
6
7
8
9
10
11
12
13
def review_edit_node(state):
current_state = {
"text": state.get("text", ""),
"metadata": state.get("metadata", {})
}

# 中断等待人工编辑
edited_state = interrupt({
"current_state": current_state,
"instruction": "请审查并编辑当前状态"
})

return edited_state

3. 审查工具调用模式(Review Tool Calls)

Tool中断执行流.png
在工具执行前进行人工审查,确保工具调用的正确性。

1
2
3
4
5
6
7
8
9
10
def tool_review_node(state):
tool_calls = state["proposed_tool_calls"]

# 中断等待人工确认工具调用
approved_calls = interrupt({
"tool_calls": tool_calls,
"action": "review_tool_calls"
})

return {"approved_tool_calls": approved_calls}

4. 为任何工具添加中断模式(Add Interrupts to Any Tool)

可以在任何工具执行前后添加人工干预点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
def tool_with_interrupt(state):
# 工具执行前的确认
pre_confirmation = interrupt({
"message": "即将执行工具,请确认",
"tool_name": "api_call"
})

# 执行工具
result = execute_tool(state["parameters"])

# 工具执行后的审查
post_review = interrupt({
"result": result,
"action": "review_result"
})

return {"final_result": post_review}

5. 验证人工输入模式(Validate Human Input)

对人工输入进行验证,确保输入的正确性和完整性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
def validation_node(state):
while True:
# 获取人工输入
user_input = interrupt({
"message": "请输入数据",
"validation_rules": ["required", "email_format"]
})

# 验证输入
if validate_input(user_input):
return {"validated_input": user_input}
else:
# 输入无效,继续循环
continue

使用注意事项

1. 副作用处理

  • 将带有副作用的代码(如API调用)放在interrupt之后或单独的节点中
  • 避免在中断点之前执行不可逆的操作

2. 子图调用

  • 当子图作为函数调用时,父图会从调用子图的节点开始重新执行
  • 子图会从包含interrupt的节点开始重新执行

3. 单节点多中断

  • 在单个节点中使用多个中断时,需要注意执行顺序
  • 中断的匹配是基于严格索引的,顺序很重要
  • 避免动态改变节点结构,可能导致索引不匹配

参考文档
https://deepwiki.com/langchain-ai/langgraph/4-human-in-the-loop-capabilities#common-hil-patterns
https://langchain-ai.github.io/langgraph/how-tos/human_in_the_loop/add-human-in-the-loop/#pause-using-interrupt

LlamaIndex

llamaindex_humaninloop.png
LlamaIndex会向外发送一个消息InputRequiredEvent事件,然后等待外部处理事件后回馈一个回执事件HumanResponseEvent

  • 事件驱动:使用 InputRequiredEvent 和 HumanResponseEvent 进行异步通信
  • 人工确认:危险操作需要用户明确确认(”yes” 或 “no”)
  • 异步处理:使用 async/await 模式处理异步事件
  • 流式处理:通过 stream_events() 实时处理事件流

参考文档
https://github.com/run-llama/python-agents-tutorial/blob/main/5_human_in_the_loop.py
https://docs.llamaindex.ai/en/stable/understanding/agent/human_in_the_loop/

ADK

长时间运行工具(Long-Running Tools)
这是最直接的实现方式,使用LongRunningFunctionTool来处理需要人工干预的异步操作。
核心实现流程:

  1. 初始调用:Agent调用长时间运行工具,工具立即返回pending状态和跟踪ID
  2. 等待人工干预:系统等待外部人工处理
  3. 更新工具响应:人工处理完成后,必须构造新的types.FunctionResponse并发送给Agent

adk_humaninloop.png

参考文档
https://deepwiki.com/search/human-in-the-loop_c1195076-6732-4fa2-97fe-4a4d444faec6

magentic-ui human in loop

connection.py定义用户输入函数:更新agent运行状态等待用户输入,然后阻塞等待用户输入
magentic_human_1.png
magentic_human_2.png

将user_input包装为Agent
magentic_human_3.png

Agent作为team的参与者,被分发
magentic_human_4.png

参考文档
https://github.com/microsoft/magentic-ui

为什么需要长期记忆

  • 从过去的经验中学习,得到处理问题的一般模式

    Without proper memory systems, AI applications would treat each interaction as completely new, losing valuable context and personalization opportunities.

  • 长期记忆作为RAG的一部分,增强大模型回答领域问题的能力,而预训练专注于一般性问题的回答性能

长期记忆模式

1. 从对话提取长期记忆

long_term_process

使用文件系统来作为上下文

使用文件来作为观察结果(如网页搜索工具的结果)的存储,而不是将所有内容都存储于内存上下文,模型需要按需读取加载到上下文,好处是可恢复的,因为文件系统中存储的是完整的内容而不是压缩后的内容
use_file_system_as_context.png

MemoryTemplate

定义
MemoryTemplate是LangChain AI提供的长期记忆服务模板,用于构建和部署可连接到任何LangGraph代理的长期记忆服务,实现用户范围的记忆管理。

核心特性

  • 分离关注点:将应用逻辑(聊天机器人)与记忆(记忆图)分离
  • 最小开销:从应用热路径中移除记忆创建逻辑,降低延迟成本
  • 后台处理:记忆创建逻辑在后台作业中处理,避免重复处理
  • 独立部署:记忆图可以独立于应用程序更新和托管

主要功能

  1. 长期记忆管理:让AI应用从每次用户交互中学习
  2. 用户适应:根据用户个人喜好和偏好进行适应
  3. 错误学习:从之前的错误中学习并改进
  4. 记忆存储:提供可靠的记忆存储层,跨对话持久化信息

技术架构

  • 记忆图:独立的记忆处理服务
  • 存储层:内置的记忆存储系统
  • 命名空间:按用户ID和记忆模式进行命名空间管理
  • API接口:通过LangGraph API进行交互

记忆模式

  1. Patch Schema模式:允许更新单个连续的记忆模式

    • 支持更新现有记忆
    • 可自定义JSON模式
    • 适用于用户信息维护
  2. Insertion Schema模式:允许插入单独的”事件”记忆

    • 跟踪关键信息片段
    • 支持对话摘要
    • 适用于事件记录

集成方式

  • 支持Anthropic Claude模型
  • 支持OpenAI GPT模型
  • 提供LangGraph Studio集成
  • 支持云部署和本地部署

评估和优化

  • 提供评估示例和测试用例
  • 支持LangSmith集成进行系统优化
  • 可自定义记忆类型和模式
  • 支持精确度和召回率平衡

提取

langextract

LangExtract是一个Python库,使用LLM从非结构化文本文档中提取结构化信息,基于用户定义的指令。它能够处理各种材料,如临床文本、法律文件、学术论文等,并输出结构化的JSON数据。

核心特性

  • 精确源定位:每个提取的实体都包含精确的源文本引用
  • 可扩展性:支持处理长文档和并行处理
  • 自定义提取:通过提示词和示例控制提取行为,从非结构化文本中提取实体、关系和属性

技术架构

  • 基于LLM的信息提取
  • 支持自定义模型提供商
  • 提供插件系统扩展功能
  • 支持本地和云端模型部署

引用链接

LightRAG

定义
LightRAG是一个简单且快速的检索增强生成(Retrieval-Augmented Generation)系统,专注于提供高效的知识检索和生成能力。

核心特性

  • 简单高效:设计简洁,易于部署和使用
  • 快速检索:优化的检索算法,提供快速响应
  • 知识图谱集成:支持知识图谱增强的检索
  • 多模态支持:可扩展支持多种数据类型
  • Web界面:提供友好的Web用户界面

主要功能

  1. 智能检索:基于语义相似度的文档检索
  2. 上下文增强:为LLM提供相关上下文信息
  3. 知识图谱:利用图结构增强检索效果
  4. 实时查询:支持实时文档查询和生成

技术架构

  • 基于向量数据库的检索系统
  • 集成知识图谱技术
  • 支持多种LLM模型
  • 提供RESTful API接口

性能优势

  • 相比传统RAG方法,在多个指标上表现优异
  • 在Comprehensiveness、Diversity、Empowerment等维度上显著提升
  • 支持大规模文档集合的高效检索

生态系统

  • RAG-Anything:多模态RAG系统
  • VideoRAG:极长上下文视频RAG
  • MiniRAG:极简RAG实现

项目信息

相关项目

为Memory建立索引和检索

https://blog.langchain.com/semantic-search-for-langgraph-memory/

memu

https://github.com/NevaMind-AI/memU

MemoryScope

定义一个pipeline来处理记忆
https://github.com/modelscope/MemoryScope

什么时候需要智能体

https://blog.crewai.com/build-agents-to-be-dependable/

什么时候需要多智能体

https://cognition.ai/blog/dont-build-multi-agents

什么时候构建multi agent
https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/
https://www.anthropic.com/engineering/multi-agent-research-system?ref=blog.langchain.dev
https://mp.weixin.qq.com/s/OpuIHSwrq3vzVxNRmqogJQ
https://www.camel-ai.org/blogs/project-oasis-automation-or-simulation---the-biggest-potential-of-multi-agent-systems
AI Agent知识库
https://geek-agi.feishu.cn/wiki/NmcawMYuii4OxFkLxLrcuQRJnPg
构建Agent的12因素
https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md
构建感知上下文的Agent
https://arxiv.org/pdf/2402.01968
自我验证的Agent架构
https://arxiv.org/pdf/2506.01716
Agent白皮书
https://zhuanlan.zhihu.com/p/16788814512

概述

基础的 ReAct 模式将action描述为 tool ,tool为沟通世界的桥梁,但tool可以有多种解释,比如mcp as tool, agent as tool, task as tool, human as tool(human in loop)等等,task是一种进阶的能力,它是一个需要多agent配合达成的目标。
看了几种实现,可以观察到一个规律:

  • 通过一个reasoning过程来产生plan,这个plan可以在内存中,也可以被保存到一个文件,如manus的todo.md 和 cline 的 Deep Planning
  • 将plan出的任务分派给agent来执行,分配给一个agent,或多个agent来解决复杂的问题,如 claude的sub task机制 和 langgraph的Hierarchical Agent Teams机制
  • 多个task之间应该会有上下文隔离和共享机制,既需要避免上下文爆炸,又需要在某些情况下多agent之间的信息共享

claude sub task

claude_task.png
某些实现会创建 Task 给一组 Agent 执行,这意味着工具实现具有很大自由度。例如 Claude Code 将子任务执行封装为 task 工具,执行结果返回给调用该工具的 agent,并合并到主 Context 中

参考文档
Claude Code Task工具与Agent架构完整技术实现分析

langgraph Hierarchical Agent Teams

hierarchical_agent_teams_process.png
随着智能体系统的发展,单一智能体可能会遇到工具选择困难(工具过多时决策质量下降)、上下文复杂度失控(难以跟踪复杂上下文)以及专业化需求(需要多个专业领域)等问题。多智能体系统通过模块化(独立开发维护)、专业化(领域专家智能体)和控制性(显式通信控制)三大优势来解决这些问题,将复杂应用分解为多个小型、独立的智能体,通过层次化组织实现任务分解和协作,使用LangGraph构建智能体网络并通过状态图管理交互。
在langgraph中可以将task分配给一个 MultiAgent 的 Team 来执行

参考文档
Hierarchical Agent Teams
AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation

manus todo.md

manus 在处理复杂任务时,倾向于创建一个todo.md文件——并在任务进行过程中逐步更新它,勾选已完成的项目。

参考文档
https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

cline deep planning

Cline 的深度规划(Deep Planning)是一种基于上下文工程的智能体规划方法,通过系统性的上下文管理来优化 AI 系统的决策和执行能力。

深度规划的本质

  • 将复杂的任务分解为多层次、可执行的子任务
  • 通过上下文工程确保每个规划步骤都有充分的信息支持
  • 实现从高层目标到具体行动的端到端规划

上下文工程在深度规划中的作用

  1. Write Context(写入上下文):将规划过程中的中间状态、决策依据等写入上下文
  2. Select Context(选择上下文):根据当前规划阶段选择最相关的上下文信息
  3. Compress Context(压缩上下文):对长规划序列进行压缩,保留关键信息
  4. Isolate Context(隔离上下文):将不同规划模块的上下文隔离,避免干扰

规划状态管理

  1. 目标分解:将复杂目标分解为可管理的子目标
  2. 上下文构建:为每个子目标构建专门的上下文
  3. 规划生成:基于上下文生成具体的执行计划
  4. 执行监控:监控执行过程,动态调整规划
  5. 结果整合:将执行结果整合到整体规划中

与 ReAct 模式的对比

特性 ReAct 模式 Cline 深度规划
决策方式 即时反应式 前瞻性规划
上下文使用 简单工具调用 复杂上下文工程
任务分解 单一工具调用 多层次任务分解
执行模式 线性执行 并行+串行混合
错误处理 重试机制 规划调整机制

参考文档
https://cline.bot/blog/how-to-think-about-context-engineering-in-cline
https://x.com/shao__meng/status/1957031656692543939
https://x.com/shao__meng/status/1957682039509118989

ReAct 机制

ReAct是一种将推理(Reasoning)和行动(Acting)与语言模型相结合的通用范式,通过交错生成推理轨迹和特定任务行动来解决复杂问题,是现代大部分框架构建 Agent 的基础理论。

理论基础

核心思想

  • 语言空间中的动作(思想/推理痕迹)不影响外部环境,但更新上下文以支持未来推理
  • 推理轨迹帮助模型归纳、跟踪和更新行动计划,处理异常
  • 行动允许与外部环境交互并收集额外信息

工作机制

1. Reasoning - 通过语言推理制定高级计划,确定下一步行动

大模型推理引擎可以解析 prompt 中的 toolcalls 作为行动计划 sglang function_calling

output parser

tools_are_structured_output
另一种方案是从大模型的结构化输出中解析工具调用,而非依赖 toolcalls 能力,这种方式提供了更大的灵活性 Tools are just structured outputs

例如 ADK 的实现就采用模型的结构化输出来识别行动 ADK Planer

2. Acting - 通过外部交互获取信息,验证推理假设,更新上下文

通常使用工具(tools)进行交互,handoffs 机制可以将其他 Agent 作为可执行工具。是否定义独立 Agent 来执行 Acting 取决于任务复杂度及其价值(因为 Agent 运行成本较高)。此外,Agent 的异常恢复机制相对脆弱,可能需要 human-in-the-loop 介入,需要权衡考虑 Prompting for Agents | Code w/ Claude

plan and execute

plan_and_execute.png
当一次产生多个 Acting 时,会演进为 Plan-And-Execute 机制 Plan-and-Execute
相对ReAct机制,plan-and-execute机制具备前瞻性,每个任务的执行比较自由,可以灵活调度并行或串行执行。

3. Reasoning Loop - 重新规划,直到收敛

Agent 进行多轮循环,不断执行 Reasoning 过程。在多次循环中,Memory 会记录执行历史,Agent 基于历史不断调整策略直到问题收敛 Memory

replan

在 Plan-and-Execute 机制中称为 Re-Plan,但不同之处在于 Re-Plan 需要上下文记录 step 历史 Plan-and-Execute

适用场景

  • 知识密集型推理任务(问答、事实验证)
  • 交互式决策任务(文本游戏、网页导航)
  • 需要动态调整的复杂任务

LangGraph 中构建 ReAct Agent 的要素

react_run.png

核心运行流程

  1. 初始化阶段:用户查询 → 初始化Agent → 生成系统提示词 → 初始化上下文
  2. 多轮循环:开始ReAct循环,直到达到最大轮数或获得最终答案
  3. 推理阶段:调用LLM获取响应 → 解析LLM响应
  4. 决策分支
    • 包含Final Answer → 返回最终答案
    • 不包含Final Answer → 解析Thought和Action → 提取工具名称和参数 → 执行工具调用 → 将工具结果添加到历史 → 继续下一轮循环

构建要素

  1. 上下文管理:定义 AgentState 管理记忆和对话上下文,构建与大模型交互的 prompt schema,进行压缩、剪枝、卸载等优化
  2. 工具:提供与外部知识库、环境交互的手段,决定 Agent 的能力范围
  3. 模型选择:模型能力影响结果质量
  4. 节点编排:设计 Agent 推理节点和工具执行节点的交互流程
  5. 终止机制:防止 ReAct 无限轮询,避免死循环和资源浪费
  6. 响应解析:解析LLM输出中的Thought、Action和Final Answer

多智能体运行模式

本文档总结了当前主流的多智能体运行模式,包括Rewoo、Plan and Execute、DeepResearch等架构模式。

阅读全文 »

Context Engineering

为什么需要Context Engineering

文章强调”Communication is all you need”的理念

  • 与LLM的沟通很困难,且经常被低估
  • 许多智能体错误的根本原因在于沟通问题
  • Context Engineering正是解决这些沟通问题的关键
    AI在应用中的表现,除了模型本身能力,更关键的是能否获取“有效且准确的context”。这里的context,不只是上下文,而是模型在特定任务下能获得的真实、相关的信息。
    Context Engineering 是为Agent在执行任务的每个步骤中,精确地向上下文窗口填充恰当信息

构成

主要包含数据源的RAG、state History和Memory,然后通过Prompt Engineering来组织数据,构造模版渲染输出
rise_of_context_engineering.png

  • Prompt Engineering: Instructions for how an agent should behave are clearly enumerated in the prompt,提示词、记忆、少样本示例、工具描述.
  • Tool use: Making sure that if an agent needs access to external information, it has tools that can access it. When tools return information, they are formatted in a way that is maximally digestable for LLMs
  • Short term memory: If a conversation is going on for a while, creating a summary of the conversation and using that in the future.
  • Long term memory: If a user has expressed preferences in a previous conversation, being able to fetch that information.
  • Retrieval: Fetching information dynamically and inserting it into the prompt before calling the LLM.
阅读全文 »

概述

Open Deep Research 是一个基于 LangGraph 构建的开源深度研究系统,能够根据用户请求灵活调整研究策略,生成高质量的研究报告。该系统采用多代理架构,支持并行研究任务,并通过上下文工程优化 token 使用。

阅读全文 »

分布式系统稳定性设计

在分布式系统设计中,稳定性是最核心的要素之一。一个不稳定的系统不仅会影响用户体验,还可能导致业务损失。本文将从基本原则和具体措施两个维度来探讨分布式系统的稳定性设计。

阅读全文 »

高效汇报的艺术

汇报是职场中最重要的沟通技能之一。无论是向领导请示工作、汇报项目进展,还是寻求决策支持,一份好的汇报都能事半功倍。本文将系统性地介绍汇报的类型、核心要素和具体步骤,帮助您掌握高效汇报的技巧。

阅读全文 »
0%