agent那些事：一文带你入门agent

status

Published

type

Post

date

Apr 14, 2026

slug

agent-analysis

summary

agent 那些事

Agent 这两年很热，但很多讨论还停留在“会调用工具的大模型”这个层面。真到工程落地时，问题很快就会变成另一类：到底什么时候该用 Agent，什么时候只需要 Workflow？所谓记忆到底是不是核心能力？多 Agent 是不是天然比单 Agent 更高级？

这篇文章试着从工程实现的角度，结合我自己用oh my opencode/openagent 开发的经历，把这些问题重新梳理一遍。

一、什么时候该用 Agent？

💡

核心原则：越简单越好，避免过度设计。

对于依赖传统规则、结构稳定、输入输出边界清晰的系统，一般不需要引入 Agent，直接使用 Workflow 往往更稳、更省成本，也更容易维护。

Agent 更适合以下场景：

多轮动态决策 — 任务路径无法预先固定，需要根据中间结果灵活调整

多工具 / 多数据源交互 — 需要在多个外部系统之间协调操作

用户意图模糊 — 需要系统先理解、澄清、拆解任务，再决定执行路径

结果带有开放性 — 例如调研、分析、生成方案、制定计划等，本身就不是纯规则问题

Workflow 与 Agent 并不完全对立。很多生产系统的最佳解法，往往是 用 Workflow 承接确定性流程，用 Agent 处理不确定性环节。

二、先判断任务类型，再设计系统

设计 Agent 系统之前，一个很重要但经常被忽略的问题是：当前任务到底是自由探索型，还是可枚举状态转换型（通常有几个稳定状态）？

自由探索型任务

这类任务的特点是：路径事先很难完全写死，中间需要边做边判断下一步。

典型例子：

调研某个技术方向

分析一个产品问题

阅读资料后形成观点

基于模糊目标提出方案

这种任务更依赖模型的理解、归纳、搜索、判断和动态规划能力。

可枚举状态转换型任务

这类任务虽然也可能复杂，但整体流程通常可以拆成若干稳定状态，并且每一步从哪个状态走向哪个状态，大体是清楚的。

典型例子：

工单处理：新建 → 分类 → 分派 → 处理 → 关闭

审批流程：提交 → 校验 → 审核 → 批准 / 驳回

代码交付：生成方案 → 编写代码 → 跑测试 → 修复 → 提交

这种任务更适合用 状态机（State Machine） 或 工作流引擎（Workflow Engine） 去实现，LLM 只需要作为某些节点的能力模块。

🧭

很多看起来像“Agent 架构”的系统，落到工程实现上，本质更接近带大模型节点的状态机。真正决定系统稳定性的，往往不是“有几个 Agent”，而是：状态如何流转、失败如何恢复、人工如何介入、工具结果如何落盘。

因此，设计架构时可以多问几个更现实的问题：

当前任务能不能画成几个比较稳定的状态？

出错后是让模型“继续想”，还是回到某个明确节点重试？

多个模块之间传递的是自然语言，还是结构化状态？

人工审批插在哪一步，审批结果如何写回系统？

三、搭建Agent流程

一般来说，设计一个 Agent 系统可以遵循下面这条主线：

这条线索背后的重点不是“让模型更聪明”，而是把系统里真正影响稳定性的部分都显式设计出来。

四、常见的 Agent 架构模式

在“设计架构”这一步，常见模式有下面几类：

模式	说明	适用场景
单 Agent（ReAct / Tool-use）	一个 Agent 负责理解任务、调用工具、汇总结果	任务相对单一、工具数量可控、链路较短
多 Agent 协作	多个 Agent 分工合作，例如规划、执行、审查分别由不同角色承担	复杂任务需要多角色、多专长或多层校验
层级式（Orchestrator + Workers）	一个编排 Agent 负责任务拆解与调度，Workers 可以是工具、函数，或具备一定自主能力的子 Agent（subagent）	任务可拆解，子任务之间相对独立
Workflow + LLM 节点	整体流程由工作流控制，LLM 只在个别节点负责分类、抽取、生成、判断	流程稳定但局部需要智能决策的业务系统

先把单 Agent + 工具调用 + 状态流转做好，再考虑多 Agent，通常更稳。

五、Prompt 工程

系统指令（System Prompt）仍然是 Agent 行为的重要驱动力，但在生产环境中，重点已经不再只是“怎么写一个更厉害的 Prompt”，而是如何让模型在一个受控框架里工作。

常见关注点包括：

角色设定 — 明确 Agent 的身份、能力边界和行为风格

Few-shot 示例 — 提供典型输入输出样例，引导模型理解预期格式

输出格式约束 — 指定 JSON、Markdown 等结构化输出格式

边界条件处理 — 明确当信息不足或遇到异常时的行为（如拒答、追问、降级）

工具使用规则 — 明确哪些工具能用、何时能用、参数格式是什么、调用失败如何处理

什么是推理过程控制？

很多早期做法会强调让模型显式输出长篇 Chain-of-Thought，似乎只要“想得够多”，复杂任务就会更可靠。但工程上更常见的结论是：稳定性更多来自任务拆解、状态管理和工具约束，而不是来自更长的自然语言思维过程。

更推荐的做法通常包括：

任务拆解：把大任务拆成一系列目标明确的小步骤

结构化中间结果：让模型输出机器可读的中间结果，而不是大段随意文本

工具调用约束：限制可调用工具、调用顺序和参数格式

可检查的计划：让计划本身可被系统校验、人工修改、失败恢复

生产环境通常更关注三件事：

结果可验证：不是“看起来像对的”，而是能通过规则、测试或工具结果验证

步骤可回放：系统知道每一步做了什么，便于调试、审计和优化

失败可恢复：某一步出错时，可以回到节点重试，而不是整条链路全部重来

六、记忆与上下文管理：不是记得越多越好，而是拿到对的上下文

很多早期文章会把 Agent 的“记忆”理解为把信息长期存起来，但在当前主流实践中，更重要的往往不是“记住更多”，而是在合适的时机，把合适的信息放进当前上下文。

因此，与其单独强调记忆，不如把这一层理解为：

上下文工程（Context Engineering）+ 状态管理（State Management）+ 检索增强（Retrieval）。

更贴近实际落地的划分通常是：

会话上下文（Session Context） — 当前轮对话、系统指令、最近几步工具调用结果，以及当前任务约束

任务状态（Task State） — 当前任务的显式状态，例如计划、待办、子任务结果、失败记录、审批状态

外部知识（External Knowledge） — 文档、知识库、工单、代码、网页等，通过检索系统按需取回

用户偏好 / 档案（Profile / Preferences） — 少量稳定、结构化、可编辑的长期信息

目前主流 Agent 更常见的是下面几种做法：

滑动窗口 + 摘要压缩：保留最近关键交互，对更早内容做摘要，但摘要要可回溯，否则容易累积偏差

RAG / 按需检索：把“知道什么”交给检索系统，而不是全部塞进长期记忆

显式状态存储：把任务进度、中间结果、工具输出、审批节点存到结构化状态中

事件日志与可观测性：记录每一步决策、工具调用和失败原因，便于调试、审计和恢复

记忆写入门控：长期记忆不是越多越好，需要去重、打分、时效控制和人工可编辑能力

因此，所谓“长期记忆”在很多生产系统里并不是默认核心能力。真正关键的是：让 Agent 在当前步骤拿到完成任务所需的最小充分上下文，并用结构化状态保证流程稳定。

七、多 Agent，不一定比单 Agent 更高级

多 Agent 是一个很容易被高估的方向。它适合某些复杂场景，但并不天然优于单 Agent。

适合引入多 Agent 的情况通常包括：

任务天然可分治，不同子任务需要不同工具或专业能力

需要明确的“规划—执行—校验”分层

不同角色之间需要相互制衡，例如生成、审查、审批

但多 Agent 也会引入新的成本：

上下文传递成本：如果 Agent 之间主要依赖自然语言传递信息，容易造成信息漂移

状态同步成本：多个 Agent 同时读写共享状态时，更容易出现冲突和重复执行

调试复杂度：问题可能来自提示词、路由逻辑、工具调用、协作协议中的任意一层

所以一个更实用的经验是：能用单 Agent + 明确工作流解决的问题，不必急着拆成多 Agent。

很多“多 Agent 系统”最后稳定运行的关键，并不是 agent 数量，而是共享状态定义清楚、交接协议简单、失败路径可控。

八、安全与护栏

Agent 的风险通常不只来自“说错话”，更来自它能不能访问系统、能不能调用工具、会不会把错误决策放大成真实操作。

因此，安全与护栏至少要覆盖下面几个层面：

1. 输入安全

Prompt Injection 防护：防止外部文本诱导模型忽略系统规则

恶意内容识别：识别越权请求、社会工程、敏感数据提取等风险输入

上下文隔离：避免不可信内容与高权限系统指令混在同一层级生效

2. 输出安全

敏感信息过滤：避免输出隐私数据、密钥、内部配置、商业机密

合规检查：对特定业务场景做内容审查，例如金融、医疗、法律等

高风险操作前确认：在给出执行建议和实际执行动作之间加一道确认或审批

3. 工具调用安全

最小权限原则：Agent 只拿到完成任务所需的最低权限

工具白名单：限制可调用工具范围，而不是默认全开

参数校验：对工具调用参数做格式和范围检查

写操作分级：读、写、删除、发布、转账等操作应该有不同等级的保护

4. 执行过程护栏

最大轮次 / 最大预算限制：防止无限循环与成本失控

速率限制与熔断：避免工具风暴、异常重试和外部系统被打爆

人工介入点：在关键节点支持人工审核、驳回或接管

审计日志：记录关键决策、工具调用、参数和结果，满足调试与追责需要

5. 记忆与数据安全

长期记忆可编辑、可删除、可追踪来源

避免把未清洗的原始对话直接长期保存并参与后续决策

区分用户数据、系统数据和检索到的外部数据的信任等级

九、评估与测试

Agent 系统的难点在于，它不是一个只有固定输入输出的函数。你不仅要看最终结果，还要看过程是否稳定、工具调用是否正确、在异常情况下是否还能工作。

因此，评估与测试至少要分成几个层次来看：

1. 能力评测

这部分关注 Agent“会不会做”。

常见方式包括：

基于 Benchmark 的自动评测 — 用标准数据集或内部题集量化分类、抽取、规划、工具使用等能力

任务集评测 — 基于真实业务样本构造评测集，比通用 benchmark 更有价值

人工评审 — 对开放性任务的质量、可用性、表达方式做主观打分

2. 流程正确性测试

这部分关注 Agent“是不是按预期流程工作”。

需要重点看：

是否调用了不该调用的工具

是否遗漏关键步骤

是否在错误节点重复循环

是否正确遵守输出格式与约束

是否在需要审批时停下来

这类测试往往比单纯看最终答案更重要，因为很多系统是“结果偶尔看着还行，但过程完全不可控”。

3. 端到端回归测试

每次修改 Prompt、模型版本、工具定义、上下文拼接逻辑后，都可能引入新问题。

所以需要有一套端到端回归用例，用来验证：

老问题有没有复发

原本能完成的任务有没有退化

工具链路有没有被新的改动破坏

输出格式和系统接口是否仍兼容

4. 异常与对抗测试

很多问题并不会在正常样例里暴露出来，所以还需要专门测：

工具超时 / 返回错误

检索不到结果

用户输入含歧义或恶意注入

上下文过长导致截断

中间状态损坏或部分缺失

一个真正可上线的 Agent，不只是“正常情况能做对”，还要在异常情况下可降级、可恢复、可解释。

5. 线上观测与持续评估

上线之后，测试并没有结束。

还需要持续关注：

成功率、失败率、平均轮次、工具调用次数

成本、耗时、重试次数、人工接管比例

常见失败模式，例如规划错误、检索错误、工具参数错误、状态丢失

用户反馈中的高频抱怨点

十、总结精华

如果把这篇文章压缩成几句最重要的话，大概是这样：

不是所有问题都需要 Agent，很多时候 Workflow 更好

设计之前，先判断任务是自由探索型还是可枚举状态转换型

很多所谓 Agent 系统，本质上是带 LLM 节点的状态机

复杂任务的稳定性，更多来自状态、约束、检索和流程，而不是更长的 Chain-of-Thought

记忆不是越多越好，很多系统真正需要的是把对的信息放进对的上下文

多 Agent 不天然更高级，能不用就别滥用

很多人说AI时代学得慢就可以不用学，对于普通人来说或许是对的，面向他们的AI应用一定是足够简单且不需要复杂的知识和操作。但对于程序员来说，即便不从事agent开发的工作，了解一些基本概念也是必要的，尽管很多东西都像是受限于模型能力而不得不暂时使用的“中间态”。