Agent：从原理、架构到工程落地（上篇）

如果把"Agent"这件事从营销词里剥离出来，会发现它并不神秘。

它本质上是一套让模型在外部工具、状态、约束与反馈中持续迭代的系统工程。

很多团队在做 Agent 时，起点往往是"给模型接几个工具"，但很快就会遇到几个典型问题：

• 工具越接越多，模型反而更容易迷路
• 上下文越堆越长，效果越差
• 看起来像 Agent，实际更像一条脆弱的脚本流水线
• 一旦出错，很难定位到底是模型、提示词、工具还是状态管理的问题

真正稳定的 Agent，不是把大模型包上一层壳，而是把推理 和控制 分离，把动态决策 和确定性工程 分工清楚。

这篇文章会从三个层面重新梳理：

1. Agent 的核心原理：循环是怎么工作的
2. Agent 的架构选择：Workflow、控制模式、Harness、上下文工程
3. 工程落地方法：结合一个诊断系统案例，讲怎么做稳定、可控、可评测的 Agent

---

一、Agent 的基本运转方式：一个稳定的循环

从实现角度看，Agent 的主循环往往非常简单：

感知 -> 决策 -> 行动 -> 反馈

直到模型输出纯文本，或者任务达到终止条件，循环结束。

你可以把它抽象成下面这个结构：

while not done:
    observation = collect_context()
    action = llm.decide(observation)

    if action.type == "tool_call":
        result = run_tool(action)
        append_to_context(result)
    else:
        done = True
        return action.text

看起来很朴素，但这正是 Agent 的核心。

很多成熟实现，不管是开源框架还是官方 SDK，底层控制流基本都离不开这个循环。

为什么这个循环如此稳定？

因为它把系统拆成了两个职责边界：

• 模型负责推理

• • 选择工具
  • 分解任务
  • 生成下一步计划
  • 处理工具反馈

• 外部系统负责状态和边界

• • 工具执行
  • 权限控制
  • 上下文裁剪
  • 记忆持久化
  • 错误回退
  • 安全约束

这意味着，Agent 的能力升级，通常不是"修改循环本身"，而是通过三种方式叠加：

1. 扩展工具集和 handler
2. 调整系统提示结构
3. 把状态外化到文件或数据库

这点非常关键：
不要把循环体写成一个巨大状态机。

如果你发现主循环越来越复杂，通常不是 Agent 更强了，而是架构边界变差了。

---

二、Workflow 和 Agent 的区别：谁掌握控制权？

Anthropic 对二者有一个很清晰的区分：

• Workflow：执行路径由代码预先写死
• Agent：下一步动作由 LLM 动态决定

区别不在于有没有工具，而在于控制权掌握在谁手里。

Workflow 更像"程序"

特点是：

• 同样输入，路径固定
• 节点和分支预先定义
• 出错时有明确回退路径
• 可观测性强，延迟可预估
• 更容易做测试和 SLA 管理

Agent 更像"决策系统"

特点是：

• 下一步由模型动态判断
• 工具调用顺序不固定
• 可能自我修复，也可能自我迷路
• 轮数不固定，延迟波动更大
• 需要更强的评测、日志和边界控制

现实里，大多数产品是混合体

很多"看起来很 Agent"的系统，其实更接近 Workflow：

只是在某些节点使用了 LLM 做分类、总结或生成。

这其实没问题。

真正重要的是：任务适合什么结构。

如果任务是高确定性的，比如：

• 表单处理
• 票据审核
• 标准化报告生成
• 规则明确的诊断流程

那 Workflow 往往更稳。

如果任务有较强不确定性，需要中间推理和灵活探索，比如：

• 故障排查
• 研究分析
• 多轮协商
• 开放式信息检索

那 Agent 更合适。

---

三、五种常见控制模式：大多数 Agent 都是它们的组合

很多系统并不是"纯 Agent"或者"纯 Workflow"，而是下面五种模式的组合。

1）Prompt Chaining

把任务拆成线性步骤，每一步的输出作为下一步输入。

适合：

• 先大纲后正文
• 先翻译后润色
• 先提取后归纳

优点是简单、可控、容易调试。

缺点是灵活性有限，一旦前一步错了，后面容易连锁失真。

---

2）Routing

先判断输入属于哪一类，再路由到对应流程。

适合：

• 技术咨询 vs 账单问题
• 简单问题走轻量模型，复杂问题走强模型
• 不同业务线使用不同处理链

它本质上是"分类 + 分流"。

---

3）Parallelization

并行处理任务，常见两种形式：

• 分段法：把子任务并发执行
• 投票法：同一任务跑多次，取共识

适合高风险决策、需要多视角的场景。

比如诊断系统里，不同模型同时分析日志、指标、配置变更，再汇总判断。

---

4）Orchestrator-Workers

中央 LLM 动态拆解任务，委派给多个 worker，再汇总结果。

这是很多子 Agent 模式的原型。

中央协调者负责计划，worker 负责执行。

适合：

• 任务复杂度高
• 子任务相互独立
• 需要统一调度和结果融合

---

5）Evaluator-Optimizer

生成器先产出结果，评估器再反馈，循环优化，直到达标。

适合：

• 翻译
• 创意写作
• 方案生成
• 代码修复

它的核心不是"一次生成完美答案"，而是允许反复迭代。

---

四、为什么 Harness 比模型更关键

很多团队在讨论 Agent 时，过度关注模型选择：

"是不是换更强的模型就能解决问题？"

实际经验往往相反。

真正决定系统能否稳定运行的，很多时候是 Harness，也就是围绕 Agent 建立的测试、验证与约束基础设施。

一个完整 Harness 至少包括四部分：

1）验收基线

系统的输出到底算不算对，必须有标准。

比如诊断系统里，可以定义：

• 最终根因是否命中
• 是否引用了正确日志
• 是否给出可执行修复方案
• 是否避免误报

2）执行边界

Agent 能做什么，不能做什么，必须明确。

比如：

• 只能读日志，不能直接改配置
• 只能在沙箱环境执行命令
• 某些高风险工具必须人工确认
• 超过轮次上限必须强制收束

3）反馈信号

模型迭代需要反馈，而反馈不能全靠"感觉"。

常见反馈包括：

• 工具执行结果
• 单测 / 回归测试结果
• 约束检查结果
• 人工确认
• 监控指标变化

4）回退手段

Agent 必须允许失败安全退出，而不是无限循环。

比如：

• 回退到最近一次稳定状态
• 降级到 Workflow 模式
• 输出"不确定"并请求人工接管
• 将调查过程写入文件便于复盘

一个现实判断

在代码编写、配置生成、日志分析这类可验证任务 上，Harness 的作用尤其大。

而在开放式研究、多轮协商这类弱验证任务上，模型上限本身仍然重要，但即便如此，没有 Harness 也很难稳定交付。

---

五、上下文工程：决定 Agent 稳定性的真正核心

很多 Agent 失效，并不是模型不够聪明，而是上下文已经坏了。

Context Rot：上下文腐化

Transformer 的注意力机制不是无限智能的。

上下文越长，噪声越多，关键信号越容易被稀释。

实践里最常见的问题是：

• 无关历史太多
• 早期决策被淹没
• 工具输出堆积过长
• 状态与规则混在一起
• 压缩后丢失关键约束

于是 Agent 看似"能力退化"，其实是信息组织失败。

---

六、上下文为什么要分层

一个稳定的 Agent，通常不会把所有东西都塞进系统提示，而是按使用频率和稳定性分层管理。

1）常驻层

放：

• 身份定义
• 项目约定
• 绝对禁止项
• 持久性原则

要求：

• 短
• 硬
• 可执行

例如：

• 不能直接修改生产环境
• 不能伪造日志结论
• 输出必须标注依据来源

---

2）按需加载层

放：

• Skills
• 领域知识
• 专项操作说明

特点是：

• 只保留索引或描述符
• 需要时再加载完整内容

这是非常重要的上下文节约手段。

系统提示里只留"入口"，不要把整个知识库直接塞进去。

---

3）运行时注入层

放：

• 当前时间
• 用户 ID
• 渠道信息
• 环境变量
• 会话状态

这些都是动态变量，应该每轮按需拼入，而不是长期驻留。

---

4）记忆层

放：

• 跨会话经验
• 偏好
• 历史决策
• 曾经失败的路径

更适合写进 MEMORY.md、数据库或长期存储。

不要直接让这些内容污染系统提示。

---

5）系统层

放：

• Hooks
• 代码规则
• 权限策略
• 确定性约束

这层最好完全不进入上下文，而是由外部系统强制执行。

---

七、压缩策略：不是越短越好，而是保留顺序要对

长任务里，压缩几乎不可避免。

但压缩最容易出错的地方，不是"摘要太短"，而是摘要保留优先级错了。

常见三种压缩策略

1）滑动窗口

最简单，持续保留最近上下文。

优点：

• 实现极简
• 成本低

缺点：

• 早期决策容易丢失

适合短对话或低复杂度任务。

---

2）LLM 摘要

把历史压缩成摘要，保留关键决策和未完成事项。

更好的做法不是普通摘要，而是 branch summarization，明确保留：

• 架构决策
• 关键约束
• 未完成任务
• 回滚笔记
• 验证状态

---

3）工具结果替换

把大量工具原始输出替换为结论或结构化摘要。

适合工具调用密集型任务。

例如日志分析时，不需要把每次 grep 的原始输出都留在上下文里，保留结论和指向文件路径即可。

---

压缩时应该优先保留什么？

建议遵循这个顺序：

1. 架构决策，不得摘要
2. 已修改文件和关键变更
3. 验证状态，pass/fail
4. 未解决的 TODO 和回滚笔记
5. 工具输出，只保留结论

还要特别注意：不要改动标识符

UUID、hash、IP、端口、URL、文件名、PR 编号、commit hash 这类值，必须原样保留。

压缩时哪怕改错一位，后续工具链就可能直接失效。

---

八、为什么文件系统是很好的上下文接口

这点在工程上特别重要。

很多工具返回的是大量 JSON 或长文本。

如果把这些内容全部塞进上下文，几轮下来 token 就会爆炸。

更好的做法是：

• 工具把结果写入文件
• Agent 只记住文件路径
• 需要时通过 grep、rg、脚本或读取工具按需加载

这就是一种典型的 Dynamic Context Discovery 。

系统默认少给，只在需要时读取。

好处非常明显

• 上下文更干净
• 可追溯性更强
• 开发者也能直接查看中间产物
• 压缩更安全，不会硬丢关键细节

实际工程里，文件系统可以充当一种非常高效的上下文接口：

• 工具负责写
• Agent 负责读
• 人类负责审计

这比把一切都塞进 prompt 更稳定。

---

九、结合诊断系统：Agent 在真实场景里怎么落地

下面我们看一个更贴近工程的例子：故障诊断系统。

设想你要做一个面向线上服务的诊断 Agent，输入可能包括：

• 告警信息
• 服务日志
• 链路追踪
• 指标曲线
• 最近变更记录
• 配置快照
• 历史事故文档

目标是让系统自动完成：

1. 判断是否真实故障
2. 定位可能根因
3. 给出优先排查路径
4. 生成修复建议
5. 输出可审计诊断报告

---

十、为什么诊断系统特别适合 Agent + Workflow 混合架构

诊断任务表面上很适合 Agent，因为它需要探索和推理。

但真正工程落地时，最好不要让 Agent 完全自由发挥。

更稳的结构通常是：

1）Workflow 负责确定性部分

例如：

• 拉取监控数据
• 查询日志
• 收集最近发布记录
• 运行标准化规则
• 校验字段完整性

这些步骤是固定的，没必要交给模型决定。

---

2）Agent 负责不确定性部分

例如：

• 判断多个线索是否指向同一根因
• 识别异常模式
• 决定下一步该看哪类数据
• 在多个候选假设中排序

这些地方才是真正需要 LLM 推理的部分。

---

十一、诊断系统的一个推荐架构

可以把系统拆成五层：

A. 数据采集层

负责从各类系统中拉取原始材料：

• metrics
• logs
• traces
• deploy events
• config diff

B. 归一化层

把原始数据整理成标准结构：

• 时间轴对齐
• 字段清洗
• 服务名统一
• 变更窗口标记

C. 推理层

由 Agent 负责：

• 归纳症状
• 生成假设
• 选择下一步证据
• 动态调整排查方向

D. 验证层

把 Agent 的判断放入 Harness 中验证：

• 是否有对应证据
• 是否能被指标/日志支持
• 是否与变更窗口一致
• 是否存在更强反证

E. 输出层

生成面向人的报告：

• 现象
• 根因
• 证据链
• 修复建议
• 风险提示
• 后续动作

---

十二、一个真实的诊断流程示例

假设系统收到告警：

API p95 延迟在 10 分钟内从 120ms 升到 2.4s，错误率轻微上升。

第一步：Workflow 先做基础采集

系统自动拉取：

• 最近 30 分钟指标
• error log
• trace 样本
• 最近发布记录
• 配置 diff

这一步完全可以用 Workflow 固化。

---

第二步：Agent 进行初步判断

模型看到证据后可能提出几个假设：

• 新版本引入慢查询
• 下游依赖变慢
• 连接池耗尽
• 某个特定路由出现异常流量
• 配置变更导致超时阈值不合理

此时 Agent 不应该"直接下结论"，而应该生成证据优先级。

例如：

1. 查看发布窗口内是否有异常变更
2. 查看慢请求是否集中在某个 endpoint
3. 核对 trace 中是否卡在下游调用
4. 检查 DB / Redis 的连接池利用率

---

第三步：工具调用与反馈

Agent 调工具：

• 查询某个 endpoint 的 latency 分布
• 对比发布前后 p95/p99
• 拉取 trace 中最慢的 span
• 检查 DB timeout 日志

如果发现：

• 延迟集中在某个新接口
• trace 显示等待下游 RPC
• 最近确有一次参数改动
• 下游服务错误率同步升高

那么根因假设就会明显收敛。

---

第四步：评估与收束

这时候不是继续无限查，而是进入收束：

• 主因是什么
• 证据是否充分
• 还有哪些不确定性
• 是否建议回滚
• 是否需要人工确认

输出中必须包含：

• 结论可信度
• 关键证据链
• 未验证项
• 修复建议

---

十三、诊断系统里最容易踩的坑

1）让 Agent 直接看所有原始日志

这会迅速污染上下文，导致噪声过大。

更好的方式是先做检索和聚合，再把高密度证据喂给模型。

2）没有证据链，只给结论

Agent 可以猜，但诊断必须可解释。

没有证据链的诊断报告不能用于生产排障。

3）工具输出全量塞回上下文

这是 token 灾难的根源。

应该用文件或结构化摘要代替。

4）没有回退机制

模型一旦陷入循环，系统就会浪费大量成本。

必须设置轮数上限、置信阈值和人工接管条件。

5）把规则写成 prompt 而不是代码

比如"不要修改生产环境"这种事，最好是权限系统强制，而不是单靠模型记忆。

---

十四、Agent 的工程落地原则

如果要把 Agent 真正做成可生产、可迭代、可审计的系统，我建议遵循下面几条原则。

1）先 Workflow，后 Agent

先把稳定的流程固定下来，再把真正需要推理的部分交给模型。

2）控制权要收敛

不要让模型决定一切。

工具选择可以灵活，但边界必须明确。

3）上下文要分层

系统提示不是垃圾桶，所有内容都往里塞只会导致退化。

4）状态要外化

能写文件就别塞上下文，能进数据库就别放 prompt。

5）压缩要保留决策

摘要不是删历史，而是保留"未来仍然需要"的信息。

6）Harness 比模型更重要

验证、边界、反馈和回退决定系统能否生产可用。

7）让模型做推理，不做制度

确定性规则应该由代码、工具、权限系统来实现。

---

十五、结语：Agent 的核心不是"更聪明"，而是"更可控"

今天很多人谈 Agent，容易陷入一种误区：

认为 Agent 的本质是"更强的模型 + 更多工具"。

但从工程角度看，真正的 Agent 系统不是单纯追求聪明，而是追求：

• 推理能力
• 稳定性
• 可观测性
• 可回退性
• 可审计性
• 可扩展性

换句话说，Agent 的难点不在"让模型会做事"，而在于让模型在可控边界内持续做事。

最好的 Agent 架构，往往不是最自由的，而是最懂得分工的：

• 模型负责想
• 系统负责管
• 上下文负责记
• 文件负责存
• Harness 负责验
• Workflow 负责稳
• Agent 负责活

如果你正在做诊断系统、代码助手、运营分析助手，或者任何需要多轮推理的智能系统，希望你记住一件事：

Agent 的上限由模型决定，但下限几乎总是由工程决定。