概述

基础的 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

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

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

langgraph Hierarchical Agent Teams

随着智能体系统的发展，单一智能体可能会遇到工具选择困难（工具过多时决策质量下降）、上下文复杂度失控（难以跟踪复杂上下文）以及专业化需求（需要多个专业领域）等问题。多智能体系统通过模块化（独立开发维护）、专业化（领域专家智能体）和控制性（显式通信控制）三大优势来解决这些问题，将复杂应用分解为多个小型、独立的智能体，通过层次化组织实现任务分解和协作，使用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 模式的对比

参考文档
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 的基础理论。

理论基础

• ReAct: Synergizing Reasoning and Acting in Language Models
• Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models

核心思想

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

工作机制

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

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

output parser

另一种方案是从大模型的结构化输出中解析工具调用，而非依赖 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

当一次产生多个 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 的要素

核心运行流程

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

• How to create a ReAct agent from scratch
• LangGraph ReAct Agent Template

多智能体运行模式

本文档总结了当前主流的多智能体运行模式，包括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来组织数据，构造模版渲染输出

• 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 使用。

分布式系统稳定性设计

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

高效汇报的艺术

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

MySQL 慢SQL调优总结

为什么需要Scrum

传统方法（主要是瀑布法）效率不足且经常引起项目最终无法交付。

Scrum团队

团队效率的提升比个人能力的提升对项目完成的影响更大
卓越团队的特点：

1. 明确的目标
   他们具有希望超越寻常的目标。实现这种目标的动力促使他们超越寻常，达到卓越。他们下决心拒绝平庸，出类拔萃，这种决定改变了他们看待自己的方式，扩大了他们的能力范围。
2. 自主决策能力
   这种团队自我组织，自我管理，有能力决定如何开展工作，并获得了根据自己决定做事的授权。
3. 多功能
   这些团队具备完成项目的所有技能：计划、设计、生产、销售、分销。具有这些技能的成员相互学习，相互提高。一位设计革命性新款相机的团队成员说：“当所有团队成员都在一间大房子里办公时，某个人的信息就是你的信息，并且得来全不费功夫。你会开始思考对整个团体而言，最优选择或次优选择是什么，而不再仅仅从你个人的角度考虑问题。”
   每个团队成员都具备完成工作所需的各种技能，而不严格划分每个成员的角色，如果严格划分角色，不同角色间交流情报时就会容易产生误差。
4. 透明度高、注重信息分享
5. 团队规模
   如果团队规模过大，沟通渠道增多会带来更大的沟通成本。
   Scrum团队倾向于让每个成员都知道其他人在做什么，每个人正在做什么工作，正面临哪些挑战，取得了哪些进步等等，都是透明的。团队规模过大会影响沟通效果，进而导致团队分裂成小团体，以至于多功能的团队就不复存在了。
6. Scrum Master
   制订工作框架：冲刺、每日立会、检查与回顾。
   Scrum Master负责确保整个工作流程的顺利推进，他的工作职责是召集会议，确保团队运作过程的透明度，为团队发现障碍，并持续改进。
7. 工作制度
   不要把问题归咎于某一个人，而是寻求制度上的解决方案。

周期

1. 冲刺
   冲刺指的是项目中的一个小的迭代周期，叫冲刺会比较有紧张感。
   每个周期固定时间审视一下这个周期内团队成员做的成果
   冲刺周期是固定的，有固定期限可以让团队成员方便评估自己的节奏在每个周期能做多少事情，并且不允许团队之外的任何人给团队内成员增加任务。
2. 每日立会
   了解这个冲刺周期内各项任务的进展状况，有没有障碍，需不需要其他人来帮忙；团队的一切任务都是自主决定、自主完成的，不需要汇报。
   时间不宜过长，不应给团队带来负担。
   Scrum Master每日问3个问题示例：

• 你昨天做了什么去帮助团队完成冲刺；
• 今天你打算做什么来帮助团队完成冲刺；
• 什么因素阻碍了团队的前进之路？
  每日立会规则：
  一、每天会议召开的时间是固定的，每个成员都要出席；
  二、开会时间不能超过15分钟，每次开会都直击重点，如果有事情需要进一步讨论，可以先记录下来，在每日立会结束之后再做进一步的讨论；
  三、每个人都要积极参与，尽量让每个人都站起来开会。

避免浪费（人力）

1. 一次只做一件事
   研究报告指出，哪些最喜欢同时执行多项任务的人自制能力相对较弱，没有办法让自己长时间集中精力。
   同时执行多项任务一般不会加快速度，反而会拖累。
2. 一次把事情做完
   Scrum开发过程中的工作是有节奏的。每一个迭代期，或者说每一个冲刺期，团队都试图完成很多事情。但是“完成”意味着一款能被消费者使用的、完整的、可交付的产品。如果在迭代期的最后，事情只做了一半，你将比一点都没开始做更糟糕。你花费了资源，付出了努力和时间，最后没有得到任何成果。

一次把事情做对

如果你出了一个错误（我们都会出错），那就在发现错误时立即修改，不然就会付出代价。
生产流程应该是持续改进的，而处理问题的最佳时机是你发现问题的时候，而不是发现问题之后很久再着手解决。
出现问题不立即修复，而是放到很久之后，会浪费更多时间：当你在做一个项目的时候，大脑专注于它，你很清楚做某件事的所有原因，这时你的脑子里存在一个与之相关的复杂架构，想在几个星期后重新建立这样的架构十分困难，会花费更多时间。

工时越长，效率越低

工作时间太长的人会开始犯错，而改正错误可能会比创造新成绩花费更多的时间。工作超出负荷的员工比较不容易集中注意力，而且会影响别人也跟着分心，不久之后他们就会开始做出错误决策。
这意味着我们更应该关注完成任务的时长和质量而不是工时长短。

确保工作的合理性

有几种不合理现象：
1、目标荒谬、不切实际
2、期待过高
3、负担过重，比如繁琐的规定、没必要的汇报、会议等过多
4、情绪浪费，比如团队中某个人倾向于激怒别人、削弱团队斗志。

周期规划会

给项目划分任务
确立优先级：由产品负责人决定优先级
确定需要花费多少精力、时间和资金。怎么知道自己的速度？每个成员冲刺周期结束时复盘可以知道自己的效率如何，并且可以通过消除障碍来变得更快
让执行团队评估自己的工作
用用户故事描绘任务：角色、活动、商业价值
用户故事必须完整：独立性、可协商性（不要带太多细节）、有价值、可评估、规模小、可测试
用户故事来源：需要产品负责人拿出一半时间与购买产品的客户开展对话（了解客户对于最新产品的看法，看看自己的产品是否为客户创造了价值），还要拿出一半时间拟定待办事项清单（让团队成员知道客户重视什么、不重视什么）。

产品负责人的特点

• 第一，产品负责人需要在相关领域内掌握丰富的专业知识。
• 第二，产品负责人必须获得自主决策权。
• 第三，产品负责人必须有足够的时间与团队成员接触，向团队成员解释清楚需要做什么以及为什么要这么做。
• 第四，产品负责人必须为价值负责。

信息瀑布：人们倾向于遵从之前众人的行为 - 别人的评估意见只能拿来作为参考，以便改进自己的判断，而不是完全取代自己的判断。
光环效应：是指当认知者对一个人的某种特征形成好或坏的印象后，还倾向于据此推论该人其他方面的特征，本质上属于以偏概全的认知错误 - 评估时保证匿名性，减少互相影响
拥抱变化：一般最初的计划评估不会完美，关键在于，要在项目执行过程中及时加以调整和改进，而不是刻板地遵循计划。详细规划出能够创造出新价值的部分，至于项目中的剩余部分，计划粗略一些也无所谓。每个冲刺周期结束之际，都必须为顾客展示一些看得见、摸得着的新价值。你可以问顾客一些问题，比如，这是你要的吗？这能帮你解决一些问题吗？我们的方向是对的吗？如果答案是否定的，那么你就要修改你的计划。

二八原则

往往20%的功能可以覆盖80%的价值
1、根据产品负责人对需求优先级的排列可以确定最重要的那部分需求
2、先做最重要的MVP部分，以期快速得到市场反馈，在此基础上检查和调整产品

风险

Scrum的目的之一是降低项目研发过程中的风险，常见的风险是市场风险、技术风险和财务风险。
市场风险：Scrum注重渐进式迭代，每个周期通过show case将产品展示给客户，收集用户意见，因此可以实时对产品做出小改动，不必等到投入大量成本后再被迫做出改动。
技术风险：先做几种原型，实际加以比较。
财务风险：怎么发现自己做的产品能挣到钱？渐进式迭代+showcase

内存原理

内存映射

Linux为每个进程提供了一个独立的虚拟地址空间，分为内核空间和用户空间，且32位和64位系统中空间范围也不同。

用户态和内核态

• 用户态：进程在用户态时,只能访问用户空间内存；
• 内核态：进入内核态后,才可以访问内核空间内存

内存映射将虚拟内存地址映射到物理内存地址，这个映射是通过每个进程的页表来实现的：