本文深入探讨了AI Agent的各种工作模式，从基础的ReAct、Reflection到复杂的Routing、Multi-Agent，以及Long-Running Agent等，详细阐述了每种模式的工作原理和适用场景。文章强调了AI Agent需要具备流程化处理能力，能够像人一样思考、行动、学习和调整，并通过各种模式实现高效协作。同时，文章还介绍了Memory与Context Engineering、Agent-to-Agent Interoperability、Agent Harness等重要概念，为开发者构建智能AI系统提供了全面的理论指导和实践参考。

---

开发者们，大家好 👋

如果你使用过 ChatGPT、Claude、Gemini，或几乎任何其他 large language model，那么你已经了解基本的交互方式。

你输入一个 prompt。模型给出一个答案。通常，交互也就到此结束。

对于简单问题、撰写一封简短的邮件、解释一些代码，或快速生成一个想法，这种方式完全够用。

但当任务变得更加复杂时，事情就开始变得有趣起来。

想象一下，你要求 AI：

研究最新的市场趋势，比较多家公司，验证数据，创建一份详细报告，然后根据你发现的所有信息给出建议。

此时，单纯的 prompt → response 流程就开始显得有限了。

AI 可能需要搜索更多信息、使用外部工具、比较不同来源、将问题拆分成更小的任务、检查自己的输出、修正错误，甚至请求另一个专业 agent 来处理其中一部分工作。

这就是 agentic workflows 发挥作用的地方。与其把 LLM 当作一个只接收 prompt 并返回文本的机器，不如说，agentic workflow 为模型提供了一个流程。

它可能更像这样：

而这一点小小的变化，彻底改变了 AI 系统能够完成的事情。

模型不再只是生成文本。它开始表现得更像一个能够采取行动、完成多个步骤、在出现问题时进行调整，并持续朝目标推进的系统。

这也是 AI agents 成为工程师重要话题的原因。但当我开始深入研究 agent 架构时，我注意到了一件有趣的事情。

大多数解释都在反复介绍几种流行模式：

ReAct、Reflection、Planning、Tool Use 和 Multi-Agent systems。

这些模式仍然非常有用。

但它们已经不再构成完整的图景。

现代 agent 系统现在还会使用 routing、parallel execution、orchestrator-workers、handoffs、human approval、long-running state、context engineering、memory、evaluation loops 等模式。

因此，在这篇文章中，我希望将所有这些概念整合到一份适合初学者的指南中。我们会从让 agentic AI 流行起来的模式开始，了解它们实际是如何工作的，然后再介绍那些在真实世界 AI 系统中日益重要的新模式。没有复杂的理论，只有简单的解释、实用的示例，以及让每种模式都易于理解的可视化工作流。

让我们从基础开始。

Agentic Workflows 的实际工作方式

Agentic workflow 不同于普通的 chatbot 对话。AI agent 不会只接收一条指令并给出一个最终答案，而是可以逐步完成一项任务。

它可以决定：

• 首先要做什么
• 使用哪些工具
• 还需要哪些信息
• 结果是否已经足够好
• 以及下一步要做什么

撰写研究报告就是一个简单的例子。普通 chatbot 可能会接收你的 prompt，然后在一次响应中生成整篇报告。Agentic system 能做得更多。

它可能会：

重要的是，agent 不必在一次尝试中就把所有事情做对。它可以采取行动、查看结果、从中学习，然后决定下一步。这正是工作流显得更加智能和实用的原因。

简单来说，你可以这样理解：

这也非常类似于我们在现实生活中解决问题的方式。我们通常不会从一开始就制定一份完美的计划。我们会尝试一些方法，观察结果，做出调整，然后继续推进，直到得到一个好的结果。Agentic workflows 将同样的迭代过程带到了 AI 系统中。

2026 年你应该了解的 AI Agent 模式

💠 Reason and Act 模式（ReAct）

ReAct 代表 Reason + Act。

这个理念很简单：agent 不会在一开始就制定完整计划，而是一次处理一个步骤。它决定接下来应该发生什么，采取行动，查看结果，然后决定下一步怎么做。

你可以这样理解这个流程：

例如，想象一个正在研究某家公司的 AI agent。它可能首先决定需要这家公司的最新营收数据，于是搜索 web。检查结果后，它可能发现信息来自一篇旧文章。于是它决定去寻找最新的 earnings report。找到数据后，它就可以继续研究的下一部分。

于是，工作流变成：

这正是 ReAct 有用的地方。Agent 不需要在开始前就知道每一步。它可以**从每次行动中学习，并在过程中调整方法。**这使它特别适合那些信息会在 agent 工作过程中逐步发现的任务。

ReAct 为什么效果好

这种模式之所以有用，有几个原因。首先，它能帮助 agent 专注于当前目标，而不是试图一次解决所有问题。其次，当某种方法不起作用时，它允许 agent 进行调整。

例如：

最后，ReAct 让 agent workflow 更容易观察和调试，因为开发者可以跟踪过程中采取的行动、工具结果以及做出的决策。

ReAct 与 Planning 的对比

将它与传统的 planning 进行比较后，区别会更容易理解。

使用 pure planning：

当环境可预测时，这种方式效果很好。但有时，agent 只有在看到 Step 1 发生了什么之后，才能知道 Step 3 应该是什么。

ReAct 能更好地处理这种情况：

这就是 ReAct 成为现代 AI agents 基础模式之一的原因。它为 agent 提供了足够的结构，使其能够朝着目标推进，同时又保留了在出现新信息时改变方向的灵活性。

💠 Reflection 模式：Review、Improve、Repeat

Reflection 是最容易理解的 agent 模式之一。

基本理念很简单：

Agent 不会在生成答案后立即将其视为最终结果，而是会**审查自己的输出、寻找问题，并尝试改进。**想想我们撰写重要内容时的做法。我们通常不会写完初稿就立即发布，而是会重新阅读，找出错误，改进薄弱部分，然后创建更好的版本。基于 reflection 的 agent 采用了类似的方式。

流程通常如下：

例如，假设 AI agent 被要求撰写一篇技术文章。首先，它会创建一个草稿。

然后它审查这份草稿，可能会发现：

• 某个解释令人困惑
• 遗漏了一个重要观点
• 某些信息需要验证
• 引言过长
• 结论较弱

Agent 不会直接返回原始草稿，而是会利用这些反馈创建一个更好的版本。它可以重复这一过程，直到输出达到可接受的质量水平。

Agent 可以审查什么？

Reflection 并不总是意味着一次检查所有内容。审查可以专注于某个特定目标。

例如：

• Accuracy：事实是否正确，并且得到了适当支持？
• Clarity：读者是否容易理解？
• Writing：语气是否符合目标受众？
• Code：是否存在 bug、安全问题或不必要的复杂性？
• Research：是否遗漏了重要来源或观点？

这种模式之所以有用，是因为同一种模式可以应用于许多不同类型的任务。

一个简单的 Coding 示例

假设 agent 生成了一个 function。它不必就此停止，而是可以遵循这样的流程：

这比假设第一次生成的版本就是正确的可靠得多。对于 production systems，如果审查得到以下外部检查的支持，Reflection 会更加强大：

因此，Reflection 不一定意味着模型只是问自己：_“我做得好吗？”_它可以将 AI 评估与工具提供的真实证据结合起来。

Reflection 最适合在什么时候使用

当质量比尽快得到答案更加重要时，Reflection 特别有用。

适合的例子包括：

• 写作
• coding
• research
• analysis
• planning
• 文档生成

但对于非常简单的任务，通常没有必要使用它。

如果有人问：

“10 × 5 等于多少？”

就没有理由创建多个审查周期。当第一次答案可能不是最佳答案时，Reflection 才会体现价值。

💠 Tool Use 模式：让 AI 接触真实世界

Language model 可以进行推理、写作、总结和生成想法。但它本身存在局限。它无法自动查看今天的天气、读取你的 database、以有保证的精度进行计算、搜索最新新闻、发送 email 或调用外部 service。

这正是 tools 变得重要的地方。Tools 让 AI agent 能够执行 language model 本身之外的操作。

例如，agent 可能可以访问：

• Web search：查找当前信息
• Calculator：执行精确计算
• Database：检索或更新记录
• APIs：与外部 service 交互
• Code execution：运行程序或分析数据
• Files：读取、创建或修改文档

强大之处在于，agent 可以根据任务决定需要使用哪个 tool。

例如，假设你要求：

“Find the current stock price of a company, compare it with last year, and calculate the percentage change.”

Agent 可能会这样工作：

Language model 负责推理，而 tools 则提供它无法仅凭自身可靠完成的信息或操作。

Agent 如何选择 Tool？

假设 agent 收到不同类型的请求。

如果你问：

“What is the weather in London today?”

它可能会选择 weather API。

如果你问：

“Calculate the compound interest on ₹5 lakh for 10 years.”

它可能会使用 calculator 或 code tool。

如果你问：

“Find my latest order from the database.”

它可能会使用 database tool。

因此，基本流程变成：

Tools 可以组合使用

Agent 不受限于只能使用一个 tool。对于复杂任务，它可能会依次使用多个 tools。想象一下，让 AI agent 创建一份 competitor analysis。

它可以：

每个 tool 负责工作中的不同部分。这正是启用 tool 的 agents 比基本 chatbot 更强大的原因。

Tool 失败时会发生什么？

这正是 agentic behavior 尤其有用的地方。假设 agent 执行了 web search，但没有找到足够的信息。它不会立即放弃，而是可以尝试其他方法：

Search failed → Rewrite the query → Search againOr:API returned incomplete data → Try another sourceOr:Tool returned an error → Choose another tool → Continue

Agent 可以利用一次行动的结果来决定下一步应该做什么。

💠 Planning 模式：先思考，再执行

当任务过于复杂，无法在不做任何准备的情况下逐步处理时，Planning 模式就很有用。Agent 不会立即采取行动，而是先审视整体目标并询问：

究竟需要完成什么？

然后，它会将目标拆分成更小的任务，并按正确顺序进行组织。一个简单的 planning 流程如下：

例如，想象一下要求 AI agent 发布一个新的 SaaS landing page。

Agent 可能会创建如下计划：

1. 了解产品和目标受众
2. 研究竞争对手
3. 定义页面结构
4. 撰写文案
5. 创建设计
6. 实现页面
7. 测试响应式和性能
8. 审查并发布

重要的是，有些任务依赖于其他任务。Agent 应该先了解产品，再撰写文案。页面可能应该先完成实现，再进行最终测试。而有些工作，例如竞争对手研究和收集视觉灵感，则可能并行进行。因此，planning 不只是创建一份待办事项列表，而是理解应该发生什么、按什么顺序发生，以及为什么。

Planning 也可以发生变化

优秀的 agent 不应盲目遵循最初的计划。有时，执行过程中会出现新信息。

假设 agent 制定了如下计划：

但在研究过程中，它发现产品面向的受众与最初预期完全不同。Agent 应该能够更新计划。

因此，更现实的工作流如下：

这通常称为 re-planning，对于长期或不确定的任务尤其重要。

Planning 最适合在什么时候使用

对于包含多个阶段、依赖关系或约束条件的任务，Planning 最有用。

适合的例子包括：

• 构建一个 software feature
• 创建一份 research report
• 迁移一个大型 application
• 规划一场 marketing campaign
• 分析一个大型 codebase
• 完成一个多步骤 business workflow

当错误代价很高时，它会更加有用。如果 agent 在不了解架构的情况下就开始修改数百个文件，之后修复这些错误可能会耗费大量时间。Planning 有助于降低这种风险。

什么时候不需要 Planning

并非每项任务都需要详细计划。

如果你问：

“Convert 10 kilometers to miles.”

制定五步策略只会增加不必要的工作。Planning 在环境高度不可预测时也可能变得不那么有用。如果 agent 很可能会发现彻底改变任务的信息，那么一开始创建极其详细的计划可能是在浪费时间。在这种情况下，更轻量的方式效果更好：

记住 Planning 模式的一种简单方式是：提前思考，组织工作，然后执行，但要随时准备修改计划。

💠 Multi-Agent 模式：让专业化 Agents 协同工作

Multi-Agent 模式采用了不同的方法。我们不要求一个 AI agent 完成所有事情，而是将工作分配给多个专业化 agents。你可以把它想象成一个小团队。一个 agent 可能擅长 research，另一个专注于 coding，另一个分析数据，还有一个审查最终结果。

因此，我们不再是：

One Agent → Handles Everything

而是：

Coordinator → Research Agent + Coding Agent + Data Agent + Reviewer

核心理念很简单：

专业化 agents 通常比一个试图处理复杂任务所有部分的通用 agent 做得更好。

一个简单的例子

想象一下，你要求一个 AI system 研究一个新的 SaaS 市场，并创建一份技术产品计划。Multi-agent system 可能会这样分配工作：

Research Agent寻找竞争对手、市场趋势、客户问题以及有用的来源。

Product Agent利用研究结果定义 features、用户和产品需求。

Technical Agent设计架构、APIs、database 和 infrastructure。

Reviewer Agent检查 research、product plan 和 technical design 是否相互一致。

Coordinator Agent管理整个 workflow，并将结果整合成一个最终响应。

工作流可能如下：

专业化为什么有帮助

单个 agent 必须同时管理许多不同的职责。

例如，它可能需要在以下方面同时表现出不同能力：

• 生成想法时要有创造力
• 审查错误时要严格
• 编写代码时要具备技术能力
• 阅读数据时要善于分析
• 验证信息时要谨慎

这些目标有时会彼此冲突。Multi-agent systems 将这些职责分离开来。Research agent 可以只专注于 research，coding agent 可以只专注于 implementation，reviewer 可以只专注于发现问题。这样更容易组织整个 workflow，并且对于合适的任务来说，效果也更好。

Coordinator 很重要

在许多 multi-agent systems 中，一个 agent 会充当 coordinator 或 orchestrator。它的工作不一定是亲自完成所有任务。

相反，它会决定：

• 哪个 agent 应该处理每项任务
• agent 何时应该开始工作
• 哪些信息应该在 agents 之间传递
• 是否需要更多工作
• 如何组合最终结果

例如：

没有良好的协调机制，增加更多 agents 反而可能让系统变得更糟。

💠 Sequential Workflow 模式：一次完成一个步骤

Sequential Workflow Pattern 是构建 AI agent workflow 最简单的方式之一。在这种模式中，agent 按固定顺序遵循一系列清晰的步骤。每一步通常都依赖前一步的结果。

我们会预先定义 workflow，而不是允许 agent 自由决定下一步做什么。这样可以让流程更加可预测，也更容易控制。

示例

假设我们希望 AI system 创建一份 research report。我们可以这样设计 workflow：

在这里，每个阶段都有明确的职责。Research 完成之前不应开始 writing。Draft 创建之后才能进行 review。最终 report 只有在 review 完成后才会生成。这就是它被称为 sequential workflow 的原因。

💠 Parallel / Fan-Out 模式：同时执行独立工作

Parallel Pattern 有时也称为 Fan-Out / Fan-In，适用于一个大型任务包含多个彼此不依赖的小任务的情况。系统不会逐个完成这些任务，而是同时将它们分发出去。所有任务完成后，系统会收集并整合它们的结果。

这可以让 agent workflow 快得多。

一个简单的例子

假设我们希望 AI agent 研究三家公司：

• Google
• Microsoft
• Amazon

Sequential workflow 可能会这样做：

但 agent 没有理由必须先完成对 Google 的研究，才能开始研究 Microsoft。这些都是彼此独立的任务。

相反，我们可以并行运行它们：

这就是 Fan-Out / Fan-In 背后的理念。Fan-Out 指将一个任务拆分成多个并行任务。Fan-In 指将这些结果重新汇总到一起。

💠 Routing 模式：将每项任务发送给正确的 Agent

当一个 AI system 接收到许多不同类型的请求时，Routing Pattern 就很有用。Router 会先查看请求并决定应该将请求发送到哪里，而不是要求一个 agent 处理所有事情。你可以把它想象成一位智能接待员。接待员不会亲自解决每个问题，而是会了解你的需求，并将你转交给合适的人。AI router 的工作方式也是如此。

基本流程如下：

User Request → Understand Request Type → Choose Best Agent or Tool → Process → Return Result

一个简单的例子

想象一下，我们正在为一家 software company 构建一个 AI assistant。

用户可能会问：

• “Fix this React error.”
• “Research our competitors.”
• “Analyze this CSV.”
• “Help me with my billing issue.”

我们可能不希望一个庞大的 agent 试图在这四件事上都做到完美。

相反，我们可以将每个请求路由到不同的 agent：

React bug → Coding AgentCompetitor research → Research AgentCSV analysis → Data AgentBilling issue → Support Agent

因此，工作流变成：

Router 如何做出决定？

Router 会查看请求，并尝试理解其意图。

例如：

“Why is this API returning 500?”

Router 可能会将其分类为技术问题，并发送给 Coding Agent。

但：

“What was our revenue growth last quarter?”

可能会被发送给 Data Analysis Agent。

而：

“I was charged twice for my subscription.”

则可能会被发送给 Billing Agent。Router 可能会基于以下因素做出决定：

• 用户意图
• 主题
• 任务难度
• 所需 tools
• 权限
• 成本
• model capability

💠 Coordinator / Orchestrator-Worker 模式：一个 Agent 负责管理，其他 Agents 负责执行

当任务过于庞大或复杂，无法由一个 agent 高效处理时，Coordinator / Orchestrator-Worker Pattern 就很有用。在这种模式中，一个中央 agent 充当管理者。它了解总体目标，将工作拆分成更小的任务，把任务分配给专业化 agents，收集它们的结果，然后将所有内容整合成一个最终输出。

一个简单的例子

想象一下，我们要求 AI system：

“Create a complete market analysis for a new AI coding product.”

Orchestrator 可能会判断，这项任务包含多个不同部分。

它可以创建：

Worker 1 → Research competitorsWorker 2 → Analyze market trendsWorker 3 → Study pricing modelsWorker 4 → Identify customer pain points

所有 workers 完成任务后，orchestrator 会汇总它们的结果。

因此，流程变成：

Orchestrator 实际上做什么？

Orchestrator 不只是转发请求。它通常承担多项职责。

它可能会：

• 了解总体目标
• 决定需要哪些子任务
• 选择哪个 worker 处理每项任务
• 向每个 worker 传递正确的 context
• 监控进度
• 重试失败的任务
• 在缺少内容时要求补充工作
• 将所有结果组合成一个最终响应

你可以把它想象成项目经理。经理不一定亲自完成每项任务，但会确保正确的工作由正确的人完成。

Workers 保持专注

每个 worker 都可以比 orchestrator 简单得多。

例如：

Research Worker只搜索并总结有用信息。

Code Worker只编写或分析代码。

Data Worker只处理计算和数据集。

Review Worker只检查质量和错误。

由于每个 worker 的职责更小，它可以专注于做好一件事。

💠 Hierarchical Agent 模式：构建由管理者和专业人员组成的团队

当任务变得如此庞大，以至于一个 orchestrator 管理所有 workers 也开始变得困难时，Hierarchical Agent Pattern 就很有用。我们不再让一个中央 agent 直接控制所有事情，而是创建多个层级的 agents。你可以把它想象成一家大型公司的组织结构。最上面是一个总经理，下面可能有 team leads，而每个 team lead 下面又有专业化 workers。

例如：

Project Manager Agent

→ Research Lead→ Development Lead→ Review Lead

然后，每个 lead 管理自己的 workers。

Research Lead 可能管理：

Market Research Agent + Competitor Research Agent + Customer Research Agent

Development Lead 可能管理：

Frontend Agent + Backend Agent + Database Agent

Review Lead 可能管理：

Testing Agent + Security Agent + Quality Agent

这样就形成了一个层级结构，而不是一组扁平的 agents。

示例

想象一下，我们要求 AI system：

“Design and build a complete SaaS product.”

这是一个非常大的目标。顶层 agent 可能首先将其拆分为几个主要领域：

Product Planning、Market Research、Software Development、Testing

每个领域还可以继续拆分。

例如：

Software Development

• Frontend
• Backend
• Database
• Infrastructure

而 frontend 任务还可以进一步拆分：

Frontend

• Authentication UI
• Dashboard
• Settings
• Responsive Design

因此，工作流变成：

这就是该模式具有层级结构的原因。

💠 Handoff 模式：将任务交给正确的 Agent

当一个 agent 开始处理请求，但后来意识到另一个 agent 更适合继续处理时，Handoff Pattern 就很有用。它不会强迫第一个 agent 完成所有事情，而是将任务交接给另一个 specialist。你可以把它想象成 customer support。你可能首先与一名 general support agent 沟通。如果问题与 billing 有关，他们会将你转交给 billing team。如果是技术问题，他们会将你转交给 engineering support。AI agents 也可以采用相同的方式工作。

一个简单的例子

想象一下，你正在为一家 SaaS company 构建 AI assistant。

用户说：

“I was charged twice, and now my account is also locked.”

General support agent 可能会先了解问题。然后它意识到，实际上这里有两个不同的问题。Billing 问题应该交给 Billing Agent。Account access 问题可能需要 Account Support Agent。

因此，工作流可能如下：

然后，如果需要：

每个 agent 都负责自己最擅长的部分。

💠 Human-in-the-Loop 模式：让 AI 工作，但保持人类控制

当 AI agent 能够独立处理 workflow 的大部分内容，但某些决策仍需要人工审查或批准时，就会使用 Human-in-the-Loop Pattern。

当要执行的操作具有以下特征时，这一点尤其重要：

• 敏感
• 昂贵
• 不可逆
• 存在风险
• 具有法律重要性
• 或者 AI 难以有把握地判断

我们不会给予 agent 完全的自由，而是定义一些必须暂停并请求人工确认的节点，然后才能继续执行。

示例

想象一个 AI customer support agent。用户要求一笔小额退款。系统检查 account，确认 refund policy，并发现金额为 ₹500。Workflow 可能允许 agent 自动完成：

但现在假设退款金额是 ₹5,00,000。这就是完全不同的情况了。Workflow 可能会变成：

AI 仍然完成大部分工作。它收集信息、检查规则并准备执行操作。但最终决定权仍由人类掌握。

人工批准为什么重要

AI agents 能力很强，但仍然可能犯错。而且，并非所有错误都会造成相同的影响。如果 agent 写出一段质量稍差的文字，我们可以直接重写。

但如果 agent：

• 删除 production data
• 转移资金
• 发送 legal document
• 封锁 customer account
• 将代码部署到 production

那么错误可能会严重得多。Human-in-the-loop 会在这些操作发生前提供一个安全检查点。

💠 Review-and-Critique 模式：一个 Agent 创建，另一个 Agent 检查

当我们希望 AI system 生成某些内容，然后在接受结果前通过另一个步骤进行仔细评估时，Review-and-Critique Pattern 就很有用。

理念很简单：

**一个 agent 创建，另一个 agent 审查。**我们不让同一个 agent 生成内容后立即相信自己的工作，而是将职责分离开来。

一个简单的例子

想象一个 AI agent 撰写了一篇技术文章。第一个 agent 专注于创建草稿。

然后，reviewer agent 会检查：

• 事实是否正确？
• 是否遗漏了内容？
• 解释是否清晰？
• 是否存在没有依据的论断？
• 文章是否符合目标受众？

如果 reviewer 发现问题，它会将反馈发送给 writer。Writer 随后改进文章。

因此，工作流变成：

这个过程可以重复，直到输出达到要求的质量。

💠 Iterative Refinement / Loop 模式：持续改进，直到结果足够好

当任务无法通过一次尝试完美解决时，Iterative Refinement Pattern 就很有用。Agent 不会生成一个结果后就停止，而是会在循环中工作。它创建内容、检查结果、进行改进，并重复这一过程，直到达到停止条件。

你可以把它想象成编辑一份草稿。第一个版本可能已经不错，但很可能并不完美。因此，agent 会不断进行细微改进，直到结果达到要求的质量。

示例

想象一下，我们要求 AI agent 创建一个 landing page 标题。

第一个版本可能是：

“Build Better Software With AI.”

Agent 对其进行评估后，认为它过于宽泛。

于是它创建了另一个版本。

“Ship Production-Ready Software Faster With AI.”

然后它再次检查。也许现在信息更清晰了，但仍然太长。因此，它又改进了一次。

“Ship Better Software Faster With AI.”

工作流变成：

重要理念是，改进通过多个小周期发生，而不是通过一次巨大的尝试完成。

💠 Long-Running Agent 模式：让 Agents 跨越单次 Session 持续工作

大多数简单的 AI 任务都能很快完成。你提出问题，模型作出响应，任务就结束了。但一些现实世界的任务无法在几秒甚至几分钟内完成。

想象一下，让 AI agent：

• 迁移一个大型 codebase
• 研究数百家公司
• 处理数千份文档
• 监控一个长期 business workflow
• 构建并测试一个完整的 software feature
• 等待外部 approval 后再继续

这些任务可能需要数小时、数天，甚至更长时间。这就是 Long-Running Agent Pattern 变得重要的地方。

核心理念很简单：

Agent 应该能够停止、保存进度，并在之后继续工作，而无需从零开始。

示例

假设一个 AI coding agent 被要求：

“Migrate this large application from an old API architecture to a new one.”

Agent 不可能在一次连续的交互中完成所有工作。

相反，它可能这样工作：

之后继续：

然后：

重要的是，agent 会记住已经发生的事情。

它不会每次都重新启动整个任务。

Long-Running Agents 需要的不只是 Memory

人们很容易认为：

“只要给 agent memory，它就可以永远工作。”

但 long-running systems 需要的结构不止这些。

它们通常需要：

• 持久化状态
• checkpoints
• task queues
• retry rules
• failure recovery
• progress tracking
• timeouts
• human approval points
• 明确的停止条件

如果没有这些控制机制，long-running agent 可能会变得难以管理。

💠 Memory 与 Context Engineering：在正确的时间向 Agent 提供正确的信息

AI agents 面临的最大挑战之一并不总是 reasoning。有时，真正的问题在于 context。Agent 可能能力很强，但如果它不知道之前发生了什么、用户有哪些偏好、哪些决策已经做出，或者哪些信息真正相关，就很容易做出糟糕的决策。这就是 Memory and Context Engineering 变得重要的地方。

核心理念是：

不要把所有信息都提供给 agent，而要在它需要时提供正确的信息。

Memory 和 Context 并不相同

这两个概念密切相关，但略有不同。Memory 是系统保存下来、以便之后使用的信息。

例如：

• 之前的对话
• 用户偏好
• 已完成的任务
• 重要决策
• 项目详情
• 过去的 tool 结果

Context 是模型处理任务时当前可用的信息。

你可以这样理解：

Memory = 所有值得记住的信息

Context = Agent 当前需要的信息

这种差异很重要。

一个简单的例子

想象一下，你有一个正在处理 application 的 AI coding agent。

昨天，你告诉它：

“We use PostgreSQL, Next.js, and TypeScript. Do not change the authentication architecture.”

今天你要求它：

“Add a new user settings feature.”

没有 memory，agent 可能需要你再次解释所有内容。

有了 memory，它可以记住：

Database → PostgreSQLFrontend → Next.jsLanguage → TypeScriptAuth Architecture → Keep unchanged

但 agent 可能不需要你们之间曾经进行过的每一次对话。它只需要与当前任务相关的信息。因此，系统会检索有用的 memories，并将它们添加到当前 context 中。

流程变成：

💠 Agent-to-Agent Interoperability：让不同的 AI Agents 协同工作

到目前为止，我们讨论的大多数模式都假设 agents 属于同一个 application。

我们构建并控制所有这些 agents，而且它们可能使用相同的 framework。但当由不同团队、公司、framework 或 programming languages 构建的 agents 需要协同工作时，agentic systems 的未来会变得更加有趣。

这就是 Agent-to-Agent Interoperability 发挥作用的地方。

核心理念很简单：

一个 AI agent 应该能够发现另一个 agent，了解它能做什么，向它发送任务，接收更新，并使用其结果，而不需要知道该 agent 的内部实现方式。

你可以把它理解为，为 AI agents 提供一种彼此协作时使用的通用语言。

示例

想象一下，你的公司有一个主 AI assistant。

你要求它：

“Find our best enterprise customer, check whether they have any unpaid invoices, and schedule a meeting with their account manager.”

一个 agent 可能无法直接访问完成任务所需的所有信息。相反，工作流可以涉及多个独立 agents：

重要区别在于，这些 agents 可能不属于同一个 system。CRM agent 可能由一个 platform 提供，finance agent 可能来自另一家公司，而你的主 assistant 可能使用完全不同的 framework 构建。Agent interoperability 允许它们协同工作。

为什么需要它？

没有 interoperability，开发者通常必须为每个连接创建 custom integrations。

想象一下有：

Agent AAgent BAgent CAgent D

如果每个 agent 都需要使用自己的 custom 方式与其他 agents 通信，架构很快就会变得复杂。

你最终可能需要构建：

A ↔ BA ↔ CA ↔ DB ↔ CB ↔ D

等等。

随着 agents 数量增长，维护所有这些 integrations 会变得困难。共享 protocol 为它们提供了一种通用的通信方式。

因此，一个 agent 不需要准确了解另一个 agent 的内部工作方式，而主要需要知道：

• 这个 agent 能做什么？
• 如何与它通信？
• 如何向它发送任务？
• 如何接收结果？

这正是 Agent2Agent (A2A) 等 standards 试图解决的问题。A2A 是一个用于独立 agents 之间进行通信和协作的开放 standard，其中包括使用不同 frameworks 构建的 agents，或由不同 vendors 提供的 agents。

💠 Agent Harness 模式：让 Agent 持续运行的系统

当我们谈论 AI agents 时，大多数注意力通常都会集中在模型上。

• 你使用的是哪个模型？
• 它有多智能？
• 它的 reasoning 能力有多强？

但在真实应用中，模型只是系统的一部分。Agent 还需要一个围绕模型运行的系统，用来决定：

• 它可以使用哪些 tools
• 如何执行 tool calls
• 它应该记住哪些信息
• 何时应该 retry
• 何时应该 stop
• 何时应该由另一个 agent 接管
• 何时应该由人类批准一项操作
• 如何处理 failures
• 如何跟踪所有内容

这个围绕模型的系统通常称为 Agent Harness。

一种简单的理解方式是：

Model = Intelligence

Agent Harness = 控制 Intelligence 如何运行的系统

可以把它想象成一辆汽车

想象一下，你有一台动力极其强大的 engine。

Engine 可能产生巨大动力，但单独的 engine 并不是一辆完整的汽车。

你仍然需要：

Steering、Brakes、Transmission、Dashboard、Safety systems、Navigation

AI model 也是类似的。Model 提供 intelligence，而 harness 则为 intelligence 提供一个受控的工作环境。

因此，production agent 不再只是：

User → LLM → Answer

而是更像这样：

Harness 负责管理所有这些组件之间发生的事情。

当前的 agent runtimes 正在逐步将这一层正式化。例如，OpenAI 将围绕 agent 的 harness/control plane 描述为负责 agent loop、model calls、tool routing、handoffs、approvals、tracing、recovery 和 run state 等内容。

---

2026年AI行业最大的机会，毫无疑问就在应用层！

字节跳动已有7个团队全速布局Agent

大模型岗位暴增69%，年薪破百万！

腾讯、京东、百度开放招聘技术岗，80%与AI相关……

如今，超过60%的企业都在推进AI产品落地，而真正能交付项目的 大模型应用开发工程师 **，**却极度稀缺！

落地AI应用绝对不是写几个prompt，调几个API就能搞定的，企业真正需要的，是能搞定这三项核心能力的人：

✅RAG：融入外部信息，修正模型输出，给模型装靠谱大脑

✅Agent智能体：让AI自主干活，通过工具调用（Tools）环境交互，多步推理完成复杂任务。比如做智能客服等等……

✅微调：针对特定任务优化，让模型适配业务

目前，脉脉上有超过1000家企业发布大模型相关岗位，人工智能岗平均月薪7.8w！实习生日薪高达4000！远超其他行业收入水平！

技术的稀缺性，才是你「值钱」的关键！

具备AI能力的程序员，比传统开发高出不止一截！有的人早就转行AI方向，拿到百万年薪！👇🏻👇🏻

AI浪潮，正在重构程序员的核心竞争力！现在入场，仍是最佳时机！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

⭐️从大模型微调到AI Agent智能体搭建

剖析AI技术的应用场景，用实战经验落地AI技术。从GPT到最火的开源模型，让你从容面对AI技术革新！

大模型微调

• 掌握主流大模型（如DeepSeek、Qwen等）的微调技术，针对特定场景优化模型性能。

• 学习如何利用领域数据（如制造、医药、金融等）进行模型定制，提升任务准确性和效率。

RAG应用开发

• 深入理解检索增强生成（Retrieval-Augmented Generation, RAG）技术，构建高效的知识检索与生成系统。
• 应用于垂类场景（如法律文档分析、医疗诊断辅助、金融报告生成等），实现精准信息提取与内容生成。

AI Agent智能体搭建

• 学习如何设计和开发AI Agent，实现多任务协同、自主决策和复杂问题解决。
• 构建垂类场景下的智能助手（如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等）。

如果你也有以下诉求：

快速链接产品/业务团队，参与前沿项目

构建技术壁垒，从竞争者中脱颖而出

避开35岁裁员危险期，顺利拿下高薪岗

迭代技术水平，延长未来20年的新职业发展！

……

那这节课你一定要来听！

因为，留给普通程序员的时间真的不多了！

立即扫码，即可免费预约

「AI技术原理 + 实战应用 + 职业发展」

「大模型应用开发实战公开课」

👇👇

👍🏻还有靠谱的内推机会+直聘权益！！

完课后赠送：大模型应用案例集、AI商业落地白皮书