第 25 章 长期 Agent 的基础设施挑战

当 Agent 从"一次性对话"演进为"持续数天运行的自治系统"，核心瓶颈从模型智力转移到基础设施——上下文窗口断裂、多模型编排成本、模型对齐缺口、以及 Harness 与模型的路线之争，共同构成了长期 Agent 工程化的四重挑战。

25.1 长周期 Agent 的运行模式

25.1.1 双层 Agent 架构：Initializer + Coding Agent

让 Agent 写一个贪吃蛇只需要一个会话。但当任务变成开发一个拥有数百个功能的全栈应用，Agent 必须连续工作数天。上下文窗口必然耗尽，每次新开会话 Agent 都会"失忆"。

业界的核心解法是 双层 Agent 架构：将"规划"与"执行"严格分离，通过结构化外部记忆实现跨会话状态恢复。

Initializer Agent（初始化 Agent） 在第一个会话中不写任何业务代码。它的唯一任务是搭建环境和拆解需求：

• 生成自动化启动脚本
• 将模糊需求分解为包含数百个细节的 结构化功能清单（JSON 格式）
• 关键约束：所有功能的状态必须被硬编码为 "passes": false，且严禁 Agent 删除或编辑测试用例字段——堵死"降低验收标准来宣布完工"的捷径

{
  "features": [
    {
      "id": "auth-001",
      "description": "用户注册与邮箱验证",
      "passes": false,
      "test_cases": ["注册成功", "重复邮箱拒绝", "验证码过期处理"]
    }
  ]
}

Coding Agent（编码 Agent） 在后续每个独立会话中只执行增量开发。每次启动时执行固定的 状态恢复 SOP：

1. 运行 pwd 确认工作目录
2. 读取 Git commit log 和进度文件，了解"上一个自己"做了什么
3. 读取功能清单 JSON，挑选 一个且仅一个 未完成的功能
4. 完成该功能后跑通测试，将状态改为 "passes": true，写下详细的 Git commit message 作为下一次会话的记忆
5. 强制退出当前会话

这种"单步推进"的设计反直觉但至关重要——严禁 Agent 试图一口气写完整个应用。每次只做一个功能、验证一个功能、记录一个功能，是对抗上下文断裂的最可靠策略。

graph TB
    subgraph "Session 0: Initializer Agent"
    I[初始化 Agent] --> S["搭建环境<br>init.sh"]
    I --> P["生成功能清单<br>features.json"]
    I --> T["所有 passes = false"]
    end

    subgraph "Session N: Coding Agent"
    R["状态恢复 SOP<br>pwd / git log / progress"] --> F["选取一个<br>未完成功能"]
    F --> C["编码 + 测试"]
    C --> U["passes = true<br>+ git commit"]
    U --> E["强制退出"]
    end

    T -.->|"JSON 持久化"| R
    U -.->|"Git 记忆"| R

25.1.2 推理算力的"三明治策略"

对于具备不同推理能力等级的模型，算力分配不能"撒胡椒面"，而应采用 三明治分配：

阶段	算力等级	目的
规划阶段	最高（xhigh）	阅读代码库、理解需求、制定详尽计划
执行阶段	中等（high）	快速编写代码，提高效率，防止超时
验证阶段	最高（xhigh）	仔细检查错误日志，深度思考修复方案

规划和验证是模型最容易犯错的环节，值得投入最高算力；执行阶段的大部分工作是机械性的代码生成，中等算力足够。

25.1.3 "垃圾回收" Agent

AI 产生代码的速度极快，系统会迅速累积技术债务。更危险的是 Agent 会"模仿"代码库中已有的烂代码，导致 破窗效应蔓延。

解法是将"代码清理"和"文档维护"转变为后台运行的独立 Agent 任务：

Doc-gardening Agent（文档园丁）：专门扫描代码库中已改变的逻辑与旧文档之间的冲突，自动发起更新文档的 PR。它不写业务代码，只维护文档与代码的一致性。

技术债清理 Agent：定期比对代码是否偏离了架构规范（如发现重复的辅助函数、违反层级依赖的引用），自动发起重构 PR。以"高频、小额"的方式偿还技术债务，而不是等到积重难返时做大规模重构。

这类 Agent 的价值在于对抗 熵增——AI 驱动的开发速度越快，清理任务就越不能依赖人工。

25.2 多模型编排与成本

25.2.1 多模型编排作为核心壁垒

Manus 的首席科学家季逸超（Peak）在访谈中明确提出：多模型编排是应用层 Agent 公司最重要的壁垒之一。核心逻辑是——

永远给用户提供"此刻最好的体验"。不同模型厂商各有所长：

• Anthropic 在工程编码和现实任务上优势明显
• Google/Gemini 在多模态输入与索引资源上独特
• OpenAI 在推理方向投入最大

作为应用层公司，不需要参与"模型大乐透"——不用押注哪家模型公司会赢。谁进步了，应用层就受益。这意味着 Agent 框架必须具备 模型无关的编排层：按场景动态选择最优模型，按任务阶段切换推理等级，按成本约束做降级处理。

Manus 的策略是不自己训模型，把精力集中在"怎么更好地使用模型"。后者风险小得多——只要整个行业在进步，应用层就跟着进步。这种策略使得 Manus 成为多个模型厂商的 top2-top5 token 消耗客户，反过来通过合作方式影响模型演进方向。

25.2.2 成本结构像制造业，不像软件

传统 SaaS 的边际成本趋近于零——多一个用户几乎不增加成本。但 Agent 的成本结构完全不同。

Chatbot 的 input:output token 比大约是 3:1，但 Agent 场景下这个比率飙升到 100:1 甚至 1000:1。原因是 Agent 在每一步决策时都需要读取大量的环境状态（文件内容、工具返回结果、历史上下文），但实际产出的动作 token 很少。

这意味着：

• 成本与用户使用量线性相关，不存在规模效应带来的边际成本递减
• 单个高价值用户可能每月消耗数千美元的算力
• 早期产品可能"每天烧几十万美元"也要扛着上线

这种成本结构更像制造业——每多生产一件产品，原材料成本是硬性的。因此 Agent 公司需要：

1. 稳健的现金流（如 Manus 的母产品 Monica 在探索期提供盈利底盘）
2. 精细的 token 预算管理（按任务复杂度分配算力，而非平均分配）
3. 渐进式上下文披露（不把所有信息塞进 context，按需加载）

25.2.3 多模型编排层的工程设计

一个生产级的多模型编排层需要解决三个核心问题：

路由决策。根据任务类型、复杂度、延迟要求选择模型。简单分类任务用小模型，复杂推理任务用强模型，实时交互用低延迟模型。路由本身可以是一个轻量级的分类器，也可以是基于规则的策略引擎。

降级链。当首选模型不可用（限流、故障、成本超标）时，自动降级到备选模型。Manus 的降级策略更激进——如果目标服务有 MCP 接入就直接用，没有 MCP 但有 API 文档就自己读文档学会调用，连 API 都没有就用浏览器模拟人类操作。这种 三级降级（MCP > API > Browser）让 Agent 不依赖任何单一接口。

成本控制。在多模型场景下，成本控制变成了一个约束优化问题：在质量下限约束下最小化 token 开销。实践中通常通过 token 预算上限 + 阶段性算力切换（三明治策略）来实现。

graph LR
    subgraph "多模型编排层"
    Task["任务输入"] --> Router["路由决策器<br>类型 / 复杂度 / 延迟"]
    Router -->|"复杂推理"| M1["强推理模型"]
    Router -->|"代码生成"| M2["编码模型"]
    Router -->|"简单分类"| M3["轻量模型"]
    Router -->|"多模态"| M4["视觉模型"]
    end

    M1 --> Fallback["降级链<br>主模型 → 备选 → 最小可用"]
    M2 --> Fallback
    M3 --> Fallback
    M4 --> Fallback

    Fallback --> Budget["Token 预算控制器"]
    Budget --> Output["动作输出"]

25.3 模型对齐的缺口

25.3.1 Chatbot-aligned vs Agent-aligned

姚顺雨提出了一个关键判断：AI 发展的上半场核心是 方法（如何训练更强的模型），下半场核心是 任务（如何定义和评估现实世界的应用场景）。当前的大模型几乎都是为 chatbot 场景对齐的——它们被训练得擅长在单轮对话中给出完整、流畅的回答。但 Agent 场景需要的是完全不同的行为模式。

季逸超在访谈中给出了一组精确的"不匹配"清单：

急于一轮答完。Chat 模型的训练目标是单次输出闭环——用户问一个问题，模型给一个完整答案。但 Agent 需要循环"observation → action"，每一步只做一个决策，等待环境反馈后再行动。模型的"急于闭环"倾向会导致它在第一步就试图输出整个解决方案，跳过必要的环境探索。

耐心不足、质量递减。在长链路任务后期，模型的输出质量显著下滑，出现"疯狂 bullet point 简化"——本应详细分析的步骤被压缩为寥寥几行。这是因为模型在训练中从未遇到过需要持续高质量输出数十轮的场景。

上下文压力（Context Pressure）。上下文越长，模型越"想结束"——它更倾向输出 EOS（结束 token）。这在 chatbot 中是合理的（用户不想看太长的回答），但在 Agent 中是致命的——长任务的后半段恰恰是最关键的。

Reasoning model 的副作用。纯"缸中之脑"式的长思维链可能降低 instruction following 能力、提高幻觉概率。Agent 需要的是 交错式思考（interleaved thinking）——思考和工具调用交替进行的推理模式，而不是先想五分钟再行动。

25.3.2 关键能力是错误恢复，不是完美

真实环境里错误是常态：依赖缺失、网页结构变化、API 限流、权限不足、格式不符合预期。一个 Agent 在执行过程中遇到错误的概率接近 100%。

因此，最好的 Agent 不是"从不犯错"的 Agent，而是能不断找到替代路径的 Agent。错误恢复（Error Resilience）是 Agent 对齐中最被低估的维度。

当前模型在错误恢复上的典型失败模式：

失败模式	表现	根因
死循环重试	同一命令反复执行 3-5 次，每次结果相同	不会切换策略
过早放弃	遇到第一个错误就声明"无法完成"	chatbot 对齐的"闭环"倾向
幻觉修复	声称已修复但实际未运行验证	偏好给出"看起来合理的答案"
暴力重试	用更大的超时/更多的重试替代根因分析	缺少诊断式推理训练

Manus 团队给出的解法方向是 "纯血 Agent"：不堆 guardrail prompt，而是增加 Agent 的"感知/反馈能力"让它自我纠错。典型例子是数据可视化——传统做法是为各种语言、字体、排版写大量规则和提示；Manus 的做法是给 Agent 一个"看图能力"，让它自己看到乱码和重叠后修复。这解决的不只是一个已知问题，而是让泛化能力覆盖未知问题。

25.3.3 超长上下文的陷阱

一个反直觉的观点：200K+ 的超长上下文窗口对 Agent 不是关键能力。关键是模型的 压缩意识（Compression Awareness）——模型应学会把信息 offload 到文件系统，做摘要压缩并知道信息"可回取"。

超长上下文的边际收益是递减的。当上下文超过一定长度后，模型的注意力分散、检索精度下降、推理质量退化。更好的策略是：

1. 主动压缩：Agent 定期将长上下文摘要为关键信息，写入外部文件
2. 按需回取：需要详细信息时从文件系统读取，而非依赖上下文窗口中的远距离信息
3. 分层记忆：近期信息保留在上下文中，远期信息持久化到外部存储

这本质上是要求模型学会 "忘记"——有选择地丢弃不重要的上下文，保留检索路径而非全部内容。

25.4 "大模型 vs 大 Harness" 之辩

25.4.1 两条路线的核心分歧

当前 AI 工程界存在一个根本性的路线之争：

Big Model 派（唯大模型论） 认为只要底层推理模型足够强大，就不需要复杂的 Harness 框架。他们指出，Agent 的核心代码其实就是一个极简循环：

while model_returns_tool_call(response):
    result = execute_tool(response.tool_call)
    response = model.generate(context + result)

人类辛苦搭建的脚手架（Linter 约束、验证闭环、死循环检测、记忆管理），很快会被更聪明的模型本身所淘汰。

Big Harness 派 认为模型能力永远参差不齐且波动。Harness 是对模型智能的"塑形"——通过优化运行环境（重试、验证、回滚、Linter 约束），哪怕不那么顶级的模型，也能在具体任务上发挥出顶级效能。

25.4.2 只要 Prefill 瓶颈在，Harness 就有价值

这场辩论不是一个"谁对谁错"的问题，而是一个 时间尺度与项目复杂度 的问题。

对于一次性的代码生成或短平快任务，强大的基础模型确实可以直接胜任，Harness 反而显得累赘。但当项目变成需要持续数年运行、多人协作、包含遗留代码、涉及复杂横向约束（如金融合规、企业级安全）的庞大系统时，没有任何一个模型能仅凭"聪明"来对抗工程的熵增。

更本质的约束是 prefill 瓶颈。当前模型架构下，每次推理都需要 prefill 整个上下文——这是一个与上下文长度线性相关的硬开销。只要这个瓶颈存在，就意味着：

1. 上下文不是免费的：每多一行上下文，就多一分推理开销
2. 信息筛选必须在模型外部完成：不能把所有信息塞进 context 让模型自己过滤
3. Harness 的渐进式披露（Progressive Disclosure）就有工程价值：Agent 启动时只读取顶层地图，按需加载深层文档

repo/
├── AGENTS.md          # 顶层目录/地图（约 100 行），指向下方具体文档
├── docs/
│   ├── architecture/  # 整体架构设计与分层规则
│   ├── domains/       # 各业务域的详细文档
│   └── references/    # 针对特定技术的快速参考指南
├── ai/                # 专供 AI 读取和写入的记忆区
│   ├── conventions/   # 全局约定与流程
│   ├── .plan/         # 阶段性设计与执行计划
│   └── .modify/       # 变更记录与实现说明

25.4.3 最优解 = 强 Base + 优化 Harness

两条路线的统合点是清晰的：最优解永远是强基础模型 + 精炼的 Harness。

姚顺雨提出的"交互方式决定商业机会"为这个统合提供了理论支撑：对于创业者而言，不要试图在基础模型能力上与大厂硬碰硬，而应专注于设计新的"交互方式"。如果应用形态只是 Chatbot，很容易被 ChatGPT 吞噬；但如果能像 Cursor 一样重构人机协作流程，就能在巨头缝隙中生存。

Manus 团队的实践验证了这个判断。他们选择"纯血 Agent"而非"Workflow Agent"——不预设具体流程，让模型自己判断每一步该怎么走。这看起来是 Big Model 派的立场，但实际上他们在环境工程上的投入极其深重：沙箱虚拟化、面向 Agent 的工具链、渐进式信息披露、token 压缩。用季逸超的话说："做对一千件小事，比做对三件大事更重要"——每一件小事都不算什么大发明，但每一件都要做对。

这与 Bitter Lesson（苦涩的教训）的精神一致：通用方法 + 更大算力，优于堆专家规则。但"通用方法"并不意味着没有工程——它意味着 工程的焦点从"规则"转向"环境"。不是提前设计三条聪明的规则让 Agent 遵守，而是构建一个丰富的环境让 Agent 在其中自主探索和纠错。

graph TB
    subgraph "Big Model 派"
    BM["更强的基础模型"] --> Loop["极简 Agent Loop<br>while tool_call: execute"]
    end

    subgraph "Big Harness 派"
    BH["精炼的 Harness"] --> Lint["架构约束 / Linter"]
    BH --> Verify["验证闭环"]
    BH --> Memory["外部记忆管理"]
    BH --> GC["垃圾回收 Agent"]
    end

    subgraph "最优解"
    OPT["强 Base + 优化 Harness"]
    OPT --> Env["丰富的环境<br>（非硬编码规则）"]
    OPT --> Feedback["感知与反馈能力<br>（自我纠错）"]
    OPT --> Infra["基础设施抽象<br>（沙箱 / 编排 / 调度）"]
    end

    BM -.->|"模型进步"| OPT
    BH -.->|"工程积累"| OPT

25.5 工程落点

25.5.1 多模型编排层设计

生产级 Agent 系统的编排层需要覆盖三个维度：

模型选择与切换。维护一个模型能力矩阵，按任务维度（推理、编码、多模态、速度、成本）为每个 Agent 步骤选择最优模型。切换必须是无感的——上层 Agent 逻辑不应关心底层用的是哪个模型。

class ModelRouter:
    def select(self, task_type: str, budget: float, latency_ms: int) -> str:
        candidates = self.capability_matrix.query(
            task_type=task_type,
            max_cost_per_1k=budget,
            max_latency=latency_ms
        )
        # 首选最强模型，降级链自动处理故障
        return candidates[0] if candidates else self.fallback_model

上下文跨模型迁移。不同模型的 system prompt 格式、工具调用协议、token 计数方式各不相同。编排层需要一个统一的中间表示，在模型切换时自动完成格式转换。

成本归因与预算执行。每次 Agent 调用都需要记录 token 消耗并归因到具体任务。当累计成本接近预算上限时，自动切换到更低成本的模型或压缩上下文。

25.5.2 云端基础设施抽象

Agent 运行在云端而非用户电脑上，这带来了根本性的架构优势——异步执行、并发任务、环境隔离——但也引入了新的基础设施挑战。

为什么必须上云。季逸超从 AI 原生浏览器项目的失败中总结了三个教训：

1. Agent 在用户电脑上运行会"抢电脑"——AI 填表时用户滚屏会打断操作
2. 短任务人比 Agent 快，长任务才需要 Agent，但长任务要求后台执行
3. 并发（同时跑多个任务）才是效率倍增的关键，这在本地不可能实现

因此 Manus 的每个会话背后是一台隔离的、一次性的沙盒虚拟机。虚拟化路线选择 Firecracker 的全虚拟化而非 Docker——因为容器绑定 Linux 生态，很多专业软件需要 Windows 环境。

环境无关抽象。Agent 代码不应感知底层是 Docker 容器还是云端沙箱。同一个执行接口可以接入不同的后端——本地 Docker 适合调试，Daytona 或 Modal 适合大规模并发。这种抽象使得开发、测试和生产使用同一套 Agent 逻辑。

class SandboxProtocol(Protocol):
    async def execute(self, command: str, timeout: int) -> ExecuteResult: ...
    async def read_file(self, path: str) -> str: ...
    async def write_file(self, path: str, content: str) -> None: ...

# 同一接口，不同后端
local_sandbox = DockerSandbox(image="agent-env:latest")
cloud_sandbox = DaytonaSandbox(region="us-east-1", slots=40)

25.5.3 远程沙箱与计算调度

远程沙箱的核心设计要求：

全异步执行。所有操作（execute、read、write、edit）必须是异步的，避免 I/O 阻塞拖慢整个系统。每个命令有独立的超时控制，防止单个卡死命令挂起整个 Agent 会话。

环境生命周期管理。沙箱的创建、使用和销毁必须是自动化的。每个任务开始时创建干净环境，任务结束后立即销毁——避免残留状态污染后续任务。对于长期任务，需要支持 环境快照与恢复：在关键节点保存环境状态，异常时从快照恢复而非从头开始。

计算调度的核心挑战。Agent 任务的执行时间极不均匀——大多数任务几秒完成，但少数任务因复杂的环境交互可能耗时数十分钟。同步调度会导致短任务等待长任务，GPU 利用率骤降。

解法是 完全异步的调度管线：

1. 将 LLM 生成、环境交互、结果验证拆解为独立的异步任务
2. 增加冗余并行环境，避免 fail-slow 环境成为系统瓶颈
3. 通过时间分片动态划分资源，使设备在推理与执行之间灵活切换

graph LR
    subgraph "计算调度"
    Q["任务队列"] --> S1["沙箱 1<br>Task A (3s)"]
    Q --> S2["沙箱 2<br>Task B (45s)"]
    Q --> S3["沙箱 3<br>Task C (8s)"]
    Q --> S4["沙箱 4<br>Task D (2s)"]
    end

    S1 -->|"完成"| R["结果收集器<br>异步聚合"]
    S3 -->|"完成"| R
    S4 -->|"完成"| R
    S2 -->|"仍在运行"| S2

    R --> V["验证器"]
    V -->|"通过"| Done["写入结果"]
    V -->|"失败"| Retry["重新调度"]

25.5.4 Harness 模板：下一代项目脚手架

未来的演进趋势是 Harness 模板（Harness Templates） 成为新的基础设施。

过去的开发者启动新项目，选择的是 React 还是 Vue。未来的开发者启动新项目，选择的将是一套 "对 AI 友好的 Harness 架构"——它预置了：

• 结构化的外部记忆目录树（渐进式披露）
• 自定义的 Linter 与架构约束规则
• 带解释的报错机制（错误信息中注入修复指令）
• 自动化的验证闭环（提交前强制跑测试）
• 死循环检测与强制打断
• 后台运行的垃圾回收 Agent

这些模板不优化模型本身的智力，而是优化模型运行的环境。正如 Harness Engineering 的核心隐喻：为一匹千里马修建一条带有护栏、限速牌和加油站的高速公路——马可以自己跑，但绝对跑不出你划定的安全边界。

产品如 Claude Code、Codex、OpenCode 已经在实践中验证了这套理念的可行性。它们的共同特征是：不是让模型变得更聪明，而是让模型在更好的环境中工作。DeepAgents、Daytona、Modal、RunLoop 等基础设施工具则在底层提供了沙箱、调度和编排的能力支撑。

竞争的终局不是"谁的模型更强"或"谁的 Harness 更复杂"，而是 谁能把强模型和精炼的 Harness 组装成一个高效闭环的系统。这个系统的每一个组件——编排层、沙箱、调度器、验证器、记忆管理——都是基础设施挑战，而非算法挑战。长期 Agent 的瓶颈，早已从模型能力转移到了工程能力。