从 Amp 看 Agent 产品设计：薄 Agent，厚流程

2026-07-11

最近用 Agent 越多，我越觉得这类产品很容易沿着功能列表增长。

接一个新数据源，加一个工具；遇到一种新任务，加一个 Skill；模型各有所长，再放一个模型选择器。碰到 Agent 不按预期工作，就继续往 system prompt 里补规则。每次改动单独看都说得通，最后却得到一个越来越重的 Agent：它要理解几十个工具，记住一大堆互相交叉的规则，还得自己处理检索、权限、上下文和失败重试。

功能一直在增加，Agent 每轮要做的选择也越来越多。新增能力带来的收益，很容易被选择成本和上下文成本吃掉。

我更喜欢另一种设计：主 Agent 尽量薄，只负责理解目标、选择路径，以及在关键节点做判断。数据准备、权限处理、检索策略、上下文压缩、证据组织和失败兜底，交给平台内置的流程。用户看到的入口可以很少，入口背后不必简单。

这里说的流程，是广义的 Agent harness。它不只包含固定步骤，也包括模型路由、工具接口、上下文准备、middleware、subagent 和验证反馈。流程划定边界，Agent 仍然可以根据结果改变路径。

薄也有两个相连但不同的层面。用户需要决定把什么目标交给系统，主 Agent 需要决定下一步采取什么行动。产品可以同时减少两边不必要的选择，本文更关心后者：主 Agent 每轮要理解多少概念，面对多少入口。

Amp 当前的 mode、subagent 和 system model 设计，提供了一个值得观察的例子。

工具越多，Agent 每一步就越重

工具通常被当成 Agent 能力的直接体现。模型不会查日志，给它一个日志工具；不会看监控，再给它一个 Metrics 工具；需要查询服务信息，就继续加一个服务目录工具。按这个思路做下去，工具列表很快就会变成平台 API 的另一种目录。

问题在于，工具并不会因为出现在列表里就自动变成能力。模型每次调用前，都要理解工具的描述、参数和适用范围。两个工具职责接近时，它还得判断该用哪个；一次任务涉及多个数据源时，它要自己安排查询顺序、控制返回量，再把结果关联起来。

这些工作当然可以交给模型，但它们大多不是任务里最需要模型的部分。权限校验、时间窗口对齐、结果去重、分页、重试和数据裁剪都有稳定规则。让模型每次临场规划一遍，既浪费 token，也给错误留下了更多入口。

工具结果同样会占用上下文。原始日志可能有几万行，一次 Trace 会展开几十个 Span，服务元信息和发布记录里又混着大量与当前问题无关的字段。Agent 如果要亲自完成查询和清洗，真正开始判断问题时，上下文可能已经塞满了中间过程。

所以我理解的薄 Agent，并不是少接几个 API，也不是把 system prompt 写短一点。它要减少的是主 Agent 每一轮必须理解和处理的东西。

用户选任务强度，产品维护模型组合

Amp 当前提供 low、medium、high 和 ultra 四种 mode。用户选择的是任务难度，以及愿意投入的时间和成本：一个明确的小改动可以用 low，日常工作交给 medium，困难问题再切到 high 或 ultra。至于背后使用哪个模型，由 Amp 决定。

它在 Models 页面里把 Agent Mode 写成了一个组合：System Prompt、Tools 和 Model。¹ 这个定义比模型列表更重要。Mode 不只给模型名称换一层包装，它把 system prompt、tools 和 model 作为一套运行配置交付。

这也改变了用户要回答的问题。面对一个任务，我通常知道它简单还是困难，却很难准确判断 GPT、Claude 或 Gemini 的某个具体版本，在当前 prompt 和工具配置下谁更合适。把后一个问题留给产品，用户只需要决定这件事值得花多少时间和成本。

这是用户侧的减法，它本身不会自动缩小主 Agent 的工具面，却让产品有机会把模型、工具和 prompt 作为组合维护。Amp 也允许通过插件增加自定义 mode，所以它没有禁止高级用户调整模型。内置体验仍然带有很强的产品判断，不要求每个人先成为模型评测专家。

把模型藏起来有一个前提：产品得对模型外面的整套配置负责。

LangChain 在 2026 年给 Deep Agents 加入了 model-specific harness profiles。此前，不同模型共用一套 prompt、工具和 middleware；加入定制 profile 后，在一组较难的 tau2-bench 任务上，GPT 5.3 Codex 的成绩从 33% 提升到 53%，Claude Opus 4.7 从 43% 提升到 53%。²

针对 Codex，他们将默认的 edit_file 实现换成 apply_patch，将命令执行工具改名为 shell_command，同时调整了工具调用和规划相关的 prompt。Claude profile 主要调整工具使用和规划 prompt，比如要求收到工具结果后重新判断下一步，并在结论依赖文件、测试或系统状态时主动调用工具核实。

这组实验没有拆分工具名称、工具实现和 prompt 各自的贡献，但至少说明，模型与 harness 不能被当成彼此独立、可以任意替换的零件。

LangChain 的另一组实验更能说明 harness 的影响。他们保持 gpt-5.2-codex 不变，调整 system prompt、tools、middleware 和推理预算等配置，Terminal-Bench 2.0 的成绩从 52.8% 提升到了 66.5%。³ 改动里有启动时注入目录和运行环境、结束前要求验证、检测重复编辑和提示剩余时间。他们还会在多轮实验之间分析执行 trace，再针对常见失败修改 harness。

这些数字来自厂商公开的特定 benchmark，其中 tau2-bench 实验使用的还是筛选过的困难子集，文章也没有给出足够信息判断统计稳定性。它们不能证明某套 harness 对所有任务都更好，但足以提醒我们，评测时不能只看模型名称。

从产品设计上看，Amp 的 mode 可以被理解为模型与 harness 的维护边界。用户不必关心组合里的每个零件，产品则可以随着模型变化一起调整工具、prompt 和流程。

Subagent 也可以是一种工具

Amp 的 Models 页面还列出了一组 Subagents：Review 负责代码审查，Search 负责本地代码检索，Oracle 处理复杂推理和规划，Librarian 研究外部代码库，Read Thread 读取历史对话。它们分别绑定了不同模型。¹

普通 subagent 适合拆分独立任务，也能隔离大量中间输出。Amp Manual 提到，每个 subagent 有自己的上下文，主 Agent 最后只接收它的总结。⁴ 搜索过程读了多少文件，代码审查产生了多少中间判断，都不必挤进主线程。

Oracle 和 Librarian 更像两项窄能力。Oracle 背后是擅长复杂分析的 Agent，主 Agent 只需要交给它一个明确的问题；Librarian 背后包含跨代码库搜索、阅读和整理流程，对外仍然是一次研究请求。

站在内部实现看，它们是 Agent。站在主 Agent 的决策面看，它们和工具没有太大区别：输入一个范围清楚的任务，得到一份整理过的结果。主 Agent 不需要知道内部用了几轮检索、读了多少上下文，也不用直接操作那套更复杂的工具。

关键不在 subagent 的数量，而在接口有没有收窄主 Agent 的决策面。一段容易产生大量中间状态的工作被压缩成语义明确的入口，主线程只保留委派和综合判断。

一个模型不必什么都擅长

Amp 还用不同的 System Models 处理媒体分析、图片生成、标题生成和上下文压缩。当前的 View Media 使用 Gemini 3 Flash，Painter 使用 GPT Image 2，Titling 使用 Claude Haiku 4.5，Compaction 使用 GPT-5.4。¹

这些能力没有被包装成让用户手动切换主模型的理由。用户仍然在和同一个 Agent 交互，需要看图片时调用 View Media，需要生成图片时调用 Painter；标题生成与长对话压缩则由系统完成。主 Agent 只需在需要媒体分析或图片生成时使用相应能力，再利用返回结果继续工作。

复杂数据应该先整理成证据

同样的思路也适合处理平台数据。一次线上问题可能涉及日志、Metrics、Trace、服务目录、发布记录、告警和资源拓扑。如果这些数据源各自暴露一个工具，主 Agent 就得承担查询、筛选、关联和摘要的全部工作。

更合适的入口可能是“准备这次异常的证据”。系统先处理权限和时间范围，再从不同数据源取回信息，去掉重复和无关内容，最后交给 Agent 一份结构化的证据包。

证据包里可以有事件时间线、异常信号、最近变更、关键关联和原始来源。缺失的数据也要明确写出来，互相矛盾的信号不能在摘要时偷偷抹平。主 Agent 拿到这些材料后，再判断最可能的原因、还缺什么，以及下一步该验证哪条路径。

每条证据至少要记录观察到的事实、数据来源、查询时间范围、服务或资源范围、数据新鲜度，以及是否经过采样和裁剪。关联可靠度可以单独标记，但不能把相关性写成因果结论。

比如证据包不能只写“发布后错误率上升”。它应该分别记录：发布发生在 10:02，错误率从 10:05 开始上升，两条记录各自来自什么查询，同一时间是否发生过流量切换。时间邻近是观察结果，发布导致故障仍然只是待验证的假设。事实、关联和假设需要分开。

收集也要有停止条件。时间窗口内的高优先级数据源已经查询完成，关键异常可以回查，剩余来源只会增加重复信息时，流程就该交付当前证据包。权限失败、超时和数据缺失不能被当作空结果，它们本身就是输出的一部分。

这类流程很厚，交给 Agent 的接口却很窄。它不要求 Agent 记住每个数据源的查询语法，也不会把几万行原始结果直接塞进上下文。平台对数据的理解沉在流程里，模型把注意力留给证据之间的关系。

这里仍然需要保留回查原始数据的能力。摘要一旦筛错信息，Agent 会在一份看似完整的证据上得出错误结论。证据包需要附带来源、查询范围和裁剪说明，让模型或人可以继续追下去。

把复杂性藏起来，不等于把系统行为藏起来。流程查询了哪些数据、跳过了哪些来源、花了多少时间和预算，以及在哪一步发生降级，都应该能看到。窄接口如果没有可观察性，只会把可见的模型错误换成更难发现的平台错误。

哪些复杂性适合沉到流程里

判断一项复杂性是否该沉到流程里，可以看三个问题：规则是否稳定，过程里的大量中间状态是否值得进入主上下文，失败能否被程序检测。高频、强依赖平台的数据处理通常符合这些条件，适合做成内置流程。

用户目标还很模糊，或者几种解释都合理时，固定流程很难提前决定路径。跨领域取舍、风险判断和缺少统一评价标准的问题，也应该留给主 Agent。模型的价值主要在这些地方，它能结合语境处理不完整的信息，并在必要时向用户确认。

模型一直在变，流程也不能永久不动。今天用于提醒模型验证、避免重复编辑的 middleware，可能在下一代模型上已经多余。LangChain 的实验说明定制 harness 有价值，也提醒我们这些定制需要持续评测。失去评测后，厚流程很容易从帮助变成历史包袱。

做减法的是决策面

我喜欢 Amp 的地方，不是它功能少。它背后有多种模型、subagents、系统工具和上下文处理流程，系统本身并不薄。它做得克制的地方，是没有要求主 Agent 和用户同时理解这些零件。

通用 coding agent 需要覆盖更多用户和工作方式，保留更多模型、配置和扩展入口可以理解。但无论给用户还是主 Agent 增加入口，都会让对应一侧多一项需要长期理解的概念。主 Agent 适合处理目标、证据和判断，查询语法、权限、分页、压缩、重试和模型适配则有更确定的工程解法。

薄 Agent，厚流程，减少的是每一轮决策必须背负的复杂性。

#ai #agent