Agent的天花板在工程：长程Agent六大模块开发指南

The Ceiling Is Engineering: A Six-Module Guide to Long-Term Agent Development

Tech-Experiment #AI Agent#长程Agent#工程化#Runtime Harness#Memory#MCP#工作流#Orchestration#Verification
更新于
🇨🇳 中文

来源：小红书「海云日记」2026-07-20《最近在做长程Agent，聊几个工程化的体感》
参考：Anthropic《Building Effective Agents》/ Mem0 / LangGraph 实践文档

读后感：一篇比半本教材更实在的帖子

这篇小红书笔记发布于2026年7月20日，作者「海云日记」是一位在内容社区实际落地长程Agent的工程师，162次浏览，143个点赞，245个收藏——收藏远高于点赞，这正是技术干货的典型传播形态。

读完这8张截图，我的第一个反应是：他踩过的最大坑，就是我们所有人最容易踩的坑。

把长程任务的稳定性问题当成了模型能力问题。

GPT-5、Gemini、Claude 的单次推理能力确实越来越强。但当你把任务扔进一个需要跑20-30分钟的链路里，模型从来不是瓶颈。真正的瓶颈是：这条链路能不能扛住长时间运行不出岔子。

这是一个认知拐点。很多团队在这个弯处转不过来，反复换模型，换提示词，还是崩。原因不是模型不够强，是工程层没兜底。

他把解法拆成了六大块，我用这篇文章把每一块的思路和最佳实践系统梳理一遍。

背景：一条跑了20分钟的链路

这个具体的业务是：在内容社区让AI助手完成一条完整的运营闭环——

查数据 → 分析数据 → 组装报告 → 接收修正意见

平均跑下来 20 到 30 分钟。不是 prompt 调一调就能稳的那种任务。链路里任何一个工具超时，或者一次上下文溢出，整个任务就崩。

这类任务在2026年越来越常见。从代码 Agent 跑完整 PR review，到数据 Agent 做周报汇总，到客服 Agent 处理复杂工单——10分钟以上的任务已经是刚需，不是前沿探索。

演化路径：三个阶段，一个拐点

在看六大模块之前，先理解一个大背景：Agent 工程化本身经历了三代演化。

阶段一：Prompt Engineering

靠模板和示例把任务讲清楚。适合短任务、结构化任务。遇到长任务就撑不住——模型每次都是从头看，没有跨步骤的状态积累。

阶段二：Context Engineering

开始大规模接 RAG，把外部信息塞进上下文。上下文越来越大，模型看到的信息越来越多。但走到一定程度就撑不住了：任务一长，context 再大也救不回来，AI 到了二三十轮就开始选择性失忆。

阶段三：Runtime Harness

这才是现在这个阶段的核心。真正扛住长程任务的不是模型，也不是上下文，是在模型外面套的一套运行时。

在这套运行时里，把任务分解、工具调度、状态保存、错误恢复、自我反思全部工程化。AI 在这套 Harness 里持续干活，而不是在一次次孤立的推理里打零工。

六大模块详解

模块一：Context & Memory（上下文与记忆）

核心问题：AI 执行长任务时，上下文会溢出，状态会丢失，历史经验无法复用。

关键设计：工作记忆和长期记忆必须分开管理。

维度工作记忆（Working Memory）长期记忆（Long-term Memory）
内容当前任务状态、进度、中间结果历史经验、用户偏好、知识库
生命周期单次任务期间跨任务持久化
存储内存 + 任务状态机向量库 + KV 存储
操作实时读写异步写入、检索时读取

三个必须常态化的动作：

  1. 压缩（Compress）：AI 每走几步，把中间状态压缩成摘要，保留关键信息丢掉细节。不做这个，context 很快就爆。
  2. 选择（Select）：每次推理前，从长期记忆里检索和当前任务最相关的片段注入 context，而不是把所有历史全塞进来。
  3. 丢弃（Discard）：对任务进展不再有帮助的中间状态主动清除，不要让 AI 背着沉重的历史包袱做决策。

工程实现：独立成一个 Memory Service。AI 每执行完一步，自动把关键状态写进记忆池。下次任务启动时直接读取，而不是从零开始。

现有方案参考：

  • Mem0：把工作记忆和长期记忆分层管理，支持 LLM 自动提取和索引记忆条目，有 Python SDK 和云端服务
  • MemGPT / Letta：把记忆管理完全内化到 Agent 本身，Agent 有显式的 core memory + archival memory 层级
  • LangGraph Persistence：内置的状态图持久化，checkpoint 机制支持任务中断续跑

这块做扎实了，AI 跑长任务才有连续性。

模块二：Tools & MCP（工具与协议）

核心问题：工具太多，AI 选不对。

真实数据：工具注册了将近 200 个，最早 AI 选工具的准确率只有三成多。200 个工具对 AI 来说就是一本没有目录的字典，每次用 token 扫描全量工具描述，选错的概率是大概率。

解法：Active Tool Discovery

不是一次给 AI 200 个工具，而是分两步走：

步骤1：AI先判断"我需要什么类型的工具"
    ↓
步骤2：根据类型，动态检索出候选工具（5-10个）
    ↓
步骤3：AI从候选工具里选择

实测：挑中率从三成提到 80% 以上。

工具少的时候不需要这个机制；工具一旦超过 30-50 个，这个设计就值了。

MCP 标准协议：

Anthropic 在2024年底发布的 Model Context Protocol 现在是工具接口协议化的最佳选择。把所有工具接进 MCP，统一描述格式、调用方式、权限管理，一次接入之后任何支持 MCP 的 Agent 框架都能直接用。

工具文档是工具工程的核心：

Anthropic 官方指南的重点：工具文档写得好不好，直接决定 AI 选工具的准确率。每个工具的描述要清楚回答：这个工具做什么、什么时候用、参数是什么意思、边界条件是什么。

模块三：Loop & Workflow（循环与工作流）

核心问题：最简单的 ReAct 循环在长任务里会自我矛盾。

ReAct（Reason + Act）是最基础的 Agent 循环：想一步，做一步，再想，再做。任务短的时候没问题。任务一长，跑过二三十步，模型开始自我矛盾——早期的推理结论和晚期的行动出现逻辑不一致，AI 开始在循环里打转。

三代工作流的演化：

第一代：ReAct 单点循环

Think → Act → Observe → Think → Act → Observe → ...

适合 10 步以内的简单任务。超过 20 步开始不稳定。

第二代：Plan-and-Execute + Checkpoints

计划阶段：把任务拆成子任务列表
执行阶段：逐个执行子任务
检查点：每个子任务完成后验证状态，决定是否继续/调整计划

相当于给 AI 一个工作计划表，而不是让它每步现想现做。对长任务稳定性提升明显。

第三代：Branching Workflow（并行分支）

主路径：Task
    ├── 候选路径A（并行执行）
    ├── 候选路径B（并行执行）
    └── 候选路径C（并行执行）
         ↓
    验证：选出最优路径
         ↓
    合并回主路径继续执行

这一步对长程任务稳定性的提升是质变级的——单点循环和分支工作流的稳定性差几个数量级。原因是：分支设计把”单点失败导致全链路崩”变成了”某个分支失败，主路径继续走其他分支”。

Anthropic 的对应模式：

  • Prompt Chaining（提示链）→ Plan-and-Execute 的基础
  • Parallelization（并行化）→ Branching Workflow 的核心机制
  • Evaluator-Optimizer（评估-优化循环）→ 给每个分支的输出打分然后合并

模块四：Hooks & Middleware（钩子与中间件）

核心问题：AI 在长任务里会把车开翻，没有安全带。

这块的工程思路和 Web 框架的中间件设计完全一致：在 AI 的每一步行动前后，插入可配置的检查逻辑。

三层 Hook 体系：

Pre-defined Rule-based（系统层）
  → 基础约束：合规规则、安全边界、资源限制
  → 硬编码，不可覆盖

Custom User-defined（业务层）
  → 业务约束：数据格式、领域规则、用户权限
  → 可配置，按业务需求调整

Runtime-adaptive（运行时层）
  → 动态约束：根据任务执行情况实时调整策略
  → 策略引擎驱动，支持运行时热更新

关键机制：失败重试和降级规则

在 Middleware 上自定义一套失败处理逻辑：

工具调用失败 → 重试3次 → 降级到备用工具 → 跳过该步骤并记录
上下文溢出 → 触发压缩流程 → 保留关键状态继续
模型响应格式错误 → 重新解析 → 格式校验失败则回退上一步
任务执行超时 → 保存检查点 → 等待恢复信号

实测效果：把这套规则挂到 Middleware 上之后，长程任务成功率从 60% 出头直接拉到 85%。

说白了就是给 AI 装安全带，不让它在长任务里把车开翻。

模块五：Orchestration（编排）

核心问题：什么时候用 Multi-Agent，什么时候单 Agent 走到底？

这块没有标准答案，取决于任务复杂度。

线性任务链：别强行拆 Multi-Agent

如果任务链相对线性（A完成→B开始→C开始），强行拆成多个 Agent 会把通信成本和调试成本堆上去，得不偿失。单 Agent + 好的工作流足够。

复杂大任务：Multi-Agent 的三个要素

如果任务确实复杂到需要多个 Agent 并行处理：

  1. Decomposition（任务分解）：怎么把一个大任务切成可以独立执行的子任务，切割面在哪里，依赖关系怎么管理
  2. Coordination Topologies（协调拓扑）：Agent 之间的通信结构——星形（中心协调者）、链式（流水线）、网状（全互联）各有适用场景
  3. Agent Protocols（通信协议）：Agent 之间怎么传递任务状态、怎么处理一个 Agent 失败后其他 Agent 的行为

Anthropic 的 Orchestrator-Workers 模式：中心 LLM 动态拆分任务，分配给 Worker LLM 执行，最后综合结果。适合任务边界不确定、需要动态调度的场景（比如复杂代码修改，涉及多少个文件预先不知道）。

模块六：Verification（验证）

核心问题：AI 跑偏了根本不会告诉你。

这块最容易被忽视，结果证明是最重要的闭环机制之一。

没有 Verification 的长程任务会有什么问题？AI 跑偏了——目标漂移、中间结果质量差、最终输出和预期完全不符——但它不会主动告诉你。它会按照自己的理解把任务跑完，然后交出一份看起来完整实际上偏了的结果。

Verifier 的三个角色：

中间检查：每个子任务完成后，验证中间结果是否符合预期
  → 早发现早纠偏，防止错误累积

路径验证：在 Branching Workflow 里，评估各候选路径的质量
  → 选出最优分支，过滤掉低质量路径

最终质量门控：任务结束前的最终验证
  → 输出是否达标？是否需要重跑某个步骤？

工程实现思路：

Verifier 本质是一个带明确评估标准的 LLM 调用（Evaluator-Optimizer 模式）。关键是要把”什么叫做质量合格”用可检查的标准描述出来，而不是模糊的”结果要好”。

# 伪代码：一个简单的 Verifier
def verify_subtask_output(subtask_name, output, criteria):
    prompt = f"""
    子任务: {subtask_name}
    输出: {output}
    验收标准: {criteria}
    
    这个输出是否满足验收标准？如果不满足，具体哪里不符合？
    返回 JSON: {{"pass": bool, "issues": list, "suggestions": list}}
    """
    result = llm.call(prompt)
    return parse_json(result)

Verifier 挂上之后，整个任务的最终质量上了一个台阶。这一块做好了，整个运行时才算真正闭环。

三层任务复杂度框架

把六大模块放在一起，还需要理解一个关键的分层框架：长程任务的三个难度层。

层1：上下文内（Intra-Context）
  问题：工具调用失败、死循环、单次推理出错
  解法：错误恢复机制、死链跳出、重试逻辑
  每个 Agent 项目都会碰

层2：跨上下文（Cross-Context）
  问题：会话断了接不上、状态丢失、昨天做到哪一步记不住
  解法：Memory Service + 任务状态机 + Checkpoint
  ← 大多数团队卡在这里

层3：跨任务流（Cross-Task）
  问题：用户中途改需求、目标漂移、要根据新反馈重新规划
  解法：任务流漂移处理、动态重规划、目标锁定机制
  最难，需要独立的工程能力

这三层每一层背后都是一套独立的工程能力，不能糊在一起。

卡得最久的是第二层：一个用户中途关掉对话，第二天接着来，AI 应该记得昨天任务进行到哪一步。听起来简单——做起来要重建整个任务状态机。

内化 vs 外化：协同，不替代

最后一个重要认知：

内化 = 模型本身的能力（推理、理解、生成）
外化 = Harness 这一层（状态、工具、验证、错误恢复）

这两条线是协同关系，不是替代关系。

今年模型卷得很厉害，但内化能力的提升并不直接转化为长程业务上的稳定性。真正的产出要靠外化这一层去做工程化落地。

Anthropic 官方指南里的一句话可以印证这个判断：

“Success in the LLM space isn’t about building the most sophisticated system. It’s about building the right system for your needs.”

模型再强，没有 Harness 兜底，10分钟以上的任务就是跑不稳。这不是模型的问题，这是工程的问题。

六大模块速查表

模块核心问题关键技术参考方案
Context & Memory上下文溢出、状态丢失工作/长期记忆分层、压缩选择丢弃Mem0, MemGPT, LangGraph Persistence
Tools & MCP工具太多选不准Active Tool Discovery、MCP 协议化MCP, Function Calling
Loop & Workflow长任务自我矛盾Plan-and-Execute + Branching WorkflowLangGraph, OpenAI Agents SDK
Hooks & Middleware缺乏安全兜底三层 Hook + 失败重试降级规则Middleware 自定义
Orchestration多 Agent 协调Decomposition + Topology + ProtocolOrchestrator-Workers 模式
VerificationAI 跑偏不自告中间检查 + 路径验证 + 质量门控Evaluator-Optimizer 模式

一句话总结

Agent 的天花板不在模型，在工程。谁能把 Harness 搭好，谁能把状态管理做细，谁能把验证体系建全，谁就能跑出真正能落地的长程智能体。

这个方向正在从研究往工程落地上拐，速度比预想的快。

延伸阅读

© 2026 Author: Mycelium Protocol

🇬🇧 English

The Ceiling Is Engineering: Six Modules for Long-Term Agent Development

Source: XiaoHongShu post by 海云日记 (July 20, 2026) · Referenced: Anthropic Building Effective Agents / Mem0 / LangGraph

Reading Reflection: A Post Worth More Than Half a Textbook

This note describes a real production system: an AI agent running a complete operations loop in a content community — query data, analyze, assemble reports, receive feedback. Average run time: 20–30 minutes.

The author’s core lesson: the biggest mistake was treating long-task stability as a model capability problem.

GPT-5, Gemini, Claude — single-inference ability keeps improving. But in a 20-minute chain, the model was never the bottleneck. The real bottleneck was whether the pipeline could hold together under sustained operation: context window, state persistence, tool failure recovery. All of that has to be handled by the engineering layer.

The six modules are the engineering answer.

The Three-Stage Evolution

Stage 1 — Prompt Engineering: Templates and examples explain the task. Fine for short tasks; no state accumulation across steps.

Stage 2 — Context Engineering: Massive RAG, external info stuffed into context. Works until it doesn’t — at 20–30 turns, selective amnesia sets in, context size stops helping.

Stage 3 — Runtime Harness: The current phase. The model is wrapped in a runtime layer that engineers task decomposition, tool dispatch, state persistence, error recovery, and self-reflection. The AI works inside this harness, not in isolated one-shot calls.

The Six Modules

Module 1 — Context & Memory

Working memory (current task state) and long-term memory (historical experience) must be managed separately. Three operations must be routine: compress (summarize intermediate state periodically), select (retrieve only relevant history at inference time), discard (actively clear state that no longer helps). Implement as an independent Memory Service — after each step, key state writes to the pool; next task reads from it.

Reference: Mem0 (layered memory with LLM-automated extraction), MemGPT/Letta (agent-internal core/archival memory), LangGraph Persistence (state graph with checkpoints).

Module 2 — Tools & MCP

With 200 registered tools, initial accuracy was ~30%. Solution: Active Tool Discovery — don’t give the AI all 200 tools at once. First ask the AI to classify what type of tool it needs, then dynamically retrieve 5–10 candidates. Result: accuracy to 80%+.

Standardize on MCP (Model Context Protocol) for all tool interfaces — unified description format, calling convention, permission management. Tool documentation quality directly determines selection accuracy.

Module 3 — Loop & Workflow

ReAct: fine for ≤10 steps, self-contradictory at 20–30 steps. Upgrade path:

  1. Plan-and-Execute + Checkpoints: decompose into subtasks, verify state at each checkpoint before continuing
  2. Branching Workflow: run multiple candidate paths in parallel, verify each, merge the winner back to main path

The stability jump from single-loop to branching is orders of magnitude. Single-point failure → branch failure (other paths continue).

Module 4 — Hooks & Middleware

Three-layer hook system:

  • Pre-defined Rule-based (system constraints, non-overridable)
  • Custom User-defined (business rules, configurable)
  • Runtime-adaptive (dynamic, driven by strategy engine)

Wire custom retry and degradation rules to Middleware: tool failure → retry 3x → fallback tool → skip + log. Result: task success rate from ~60% → 85%.

Module 5 — Orchestration

Linear task chains don’t benefit from Multi-Agent (communication + debugging overhead). Complex tasks that genuinely need it require three components: Decomposition (how to cut tasks into independent subtasks), Coordination Topologies (star/chain/mesh — each suits different dependencies), Agent Protocols (state passing, failure handling between agents).

Module 6 — Verification

When an AI drifts off target, it doesn’t tell you. The task finishes; the output looks complete; it’s wrong.

Verifier has three roles: intermediate checks (catch drift early), path validation (score Branching Workflow candidates), final quality gate (pass/fail before delivery).

The Evaluator-Optimizer pattern (one LLM generates, another evaluates in a loop) is the right shape. Key requirement: express quality criteria as checkable standards, not vague intentions.

Three-Layer Task Complexity

  • Layer 1 (intra-context): error recovery, dead-loop exit — every project hits this
  • Layer 2 (cross-context): resume broken sessions, restore state — where most teams get stuck; requires full task state machine
  • Layer 3 (cross-task flow): handle mid-task goal changes, dynamic re-planning — hardest, independent engineering capability

Internalization vs. Externalization

Model capability = internalization. Harness engineering = externalization. These are complementary, not substitutes.

Model improvements don’t directly translate to long-task stability. The engineering layer has to close the gap. As Anthropic’s guide puts it: success in the LLM space isn’t about building the most sophisticated system — it’s about building the right system.

No harness, no stability for tasks over 10 minutes. That’s not a model problem. It’s an engineering problem.

ModuleCore ProblemKey TechReference
Context & MemoryOverflow, state lossLayered memory, compress/select/discardMem0, MemGPT, LangGraph
Tools & MCPToo many tools, wrong selectionActive Tool Discovery, MCP protocolMCP, Function Calling
Loop & WorkflowLong-task self-contradictionPlan-and-Execute, Branching WorkflowLangGraph, OpenAI Agents SDK
Hooks & MiddlewareNo safety net3-layer hooks, retry/degradation rulesCustom Middleware
OrchestrationMulti-agent coordinationDecomposition, topology, protocolOrchestrator-Workers
VerificationAI drifts silentlyIntermediate + path + final quality gatesEvaluator-Optimizer

The ceiling isn’t the model. It’s the engineering.

© 2026 Author: Mycelium Protocol

相关文章

Tech-Experiment

OpenWorker：吴恩达开源的桌面 AI 协作者，本地运行 + 批准门 + 25+ 工具集成
Tech-Experiment

OneCLI：让 AI Agent 永远看不到真实密钥的开源凭证网关
Tech-Experiment

Osaurus：在你的 Mac 上拥有 AI——密码学身份、沙盒 VM、隐私过滤，纯 Swift 原生

💬 评论与讨论

使用 GitHub 账号登录后发表评论