Agent学习笔记（一）Agent设计中的几个问题
以现有的技术调研流程为参照，讨论换成 Agent 后可以借鉴哪些经验，以及需要重新设计哪些机制。
设计 Agent，首先要明确它要完成什么，允许做什么，以及怎样检查结果。这是我系统学习 Agent 的第一篇笔记，我们先从这几个问题谈起。从宏观上看，设计一个 Agent 会涉及执行编排、记忆管理和工具调用，也会遇到多个 Agent 之间如何协作的问题。各个方面的具体实现和相关论文，我们留到后面的篇章里再展开。
我们以调研一种压缩技术为例。假设一个项目想减少日志占用的存储空间，需要先了解有哪些压缩方法，再决定是否值得采用。负责调研的人会先问清楚需求：日志能不能有信息损失，压缩和读取分别能花多少时间，最后需要一份资料介绍，还是能够支持选型的比较报告？
需求明确后，就可以查找资料、记录来源，把不同方法放在一起比较。看到“压缩后只剩原来的一小部分”这样的结论，还得看看测试用了什么数据；几份资料的结果对不上，也需要核对它们的实验条件。读过哪些内容、哪些问题还没有答案，可以记在工作文档里。最后交付报告，再由使用报告的人检查它是否回答了最初的问题。
这里已经有了一套工作流程。需求决定查什么，资料和记录帮助调研继续推进，最后的审阅负责检查结果。我们可以把这套流程作为设计新系统的参照。
假设让 Agent 来做这件事
现在，假设我们想设计一个 Agent 来完成同样的调研。仿照刚才的流程，应该怎么做？
有些经验可以直接借鉴。开始前要明确需求，查到的结论要保留来源，任务中途需要记录进度，交付后还要检查报告。但换成 Agent 之后，这些事情各自由什么机制来完成，就需要重新设计了。比如，原先读到证据不足的地方，调研者会决定继续查找；现在要由谁判断证据是否足够，又怎样让这个判断影响下一步执行？
我们先把这里讨论的 Agent 理解为一个围绕目标选择动作、根据执行结果继续推进任务的系统。模型可以在其中提出下一步动作，外围程序负责调用工具、保存状态和落实约束。一次运行可以先写成下面的过程：
1 | 目标与约束 |
这个过程与刚才的调研流程有对应的地方，但仅有对应关系还不够。模型能不能作出合适的判断，工具能不能完成操作，程序怎样发现错误，都需要进一步检查。Anthropic 的 Building effective agents 也从工具调用、环境反馈和停止条件讨论了 Agent 的运行过程。
问题一：目标是什么，怎样才算完成？
在原来的流程里，调研者收到“研究一下压缩技术”这样的要求，很可能还要追问几句。入门学习和工程选型需要的资料不同；即使都是选型，关注存储空间还是读取速度，也会影响比较的方向。设计 Agent 时，我们同样需要给它澄清需求的机会，或者在任务开始前就提供足够明确的要求。
沿着日志压缩的例子，可以先约定：交付一份带原始来源的比较报告，说明候选方法能否完整还原日志、压缩后的大小和处理时间是在什么条件下测出来的，以及这些条件与我们的项目是否接近。如果没有做实验，就不能把资料里的数字写成本项目的实测结果；暂时缺少证据的地方，也应当保留下来。
接下来还要确定，什么情况下可以交付。原先我们可以拿着需求去审阅报告，到了 Agent 系统里，也需要保留这一步。实际文件是否生成、报告有没有回答问题、引用是否支持结论，都得检查。模型回复一句“已完成”，只说明它发出了这条回复。
时间和费用也会影响任务何时停止。如果搜索预算用完了，报告却还缺证据，系统可以保存已有内容并说明缺口，但不能把预算耗尽记成成功完成。“完成”“等待补充信息”和“预算耗尽”需要有不同的状态，后续程序才知道该怎样处理。关于实际交付结果与执行记录的区分，可以参考 Demystifying evals for AI agents。
问题二：下一步由谁决定，何时需要调整？
查资料的顺序往往会随着读到的内容改变。假设一篇文章推荐某种压缩方法，却没有给出测试条件，原来的调研流程允许我们回头寻找原论文，或者暂时把这个结论记成待验证。这个经验可以带到新系统里：执行需要能够响应新发现。
具体怎样响应，则有不同的设计。我们可以预先规定“缺少测试条件就查找原始来源”，也可以把当前证据交给模型，由它判断还需要补充什么。前一种做法把分支写进程序，后一种给模型更多选择空间。哪些地方适合固定下来，哪些地方需要动态决定，要看任务中的变化究竟发生在哪里。
即使允许模型调整计划，也还需要考虑它没有取得进展的情况。连续搜索得到相同资料，工具一直失败，或者用户中途改变了要求，分别应该怎样处理？重试次数、停止条件以及必须保留的已完成工作，都要有安排。
后面学习 Workflow、ReAct 或 Plan-and-Execute 时，我们就可以围绕这些问题看它们怎样组织执行。关于预设流程与模型动态决定路径的区别，先参考 Building effective agents。
问题三：状态如何延续，中断后怎样继续？
原来的调研工作可能持续几天。把资料来源、已经确认的结论和待解决的问题记下来，下一次就能接着做。设计 Agent 时可以借鉴这个经验，但还要进一步确定：程序恢复任务究竟依赖哪些记录？
如果助手读了十几篇资料，报告写到一半，进程突然退出，重新启动后就需要知道哪些材料已经处理、报告保存到了哪里、下一步原本准备做什么。只放在进程内存里的信息，无法在进程退出后直接取回。等待用户确认、网络故障和执行中断，也都可能让一次任务分成前后几段。
还有一个单靠“记笔记”解释不了的问题。假设报告已经写进文档系统，程序却在记录“写入成功”之前崩溃了。内部进度还停在上一步，外部文件可能已经存在。恢复后直接重做，可能创建重复文件；直接跳过，又需要先确认上次确实写入成功。
因此，新系统既要保存任务进度，也要处理记录与外部实际状态之间的差异。保存什么、什么时候保存、哪些操作可以安全重试，都会影响恢复方式。到实现时，我们可以故意在写入前后中断程序，检查它会不会漏掉或重复执行操作。
问题四：这一轮应该知道什么，长期应该记住什么？
调研时，我们可能保存了很多资料，但写某一段比较时，只会打开与当前问题有关的几份。以前做过类似项目留下的经验，也可能派上用场。这几类信息用途不同，到了 Agent 中，同样需要分清。
| 概念 | 含义 | 在调研助手中的例子 |
|---|---|---|
| 运行状态 State | 系统保存的当前任务进展 | 已读资料、待解决问题、审批状态 |
| 上下文 Context | 本轮实际发送给模型的信息 | 当前目标、相关摘录、最近的工具结果 |
| 长期记忆 Memory | 为后续任务保留的可复用信息 | 用户偏好、项目约束、已验证的经验 |
比如，系统保存了 100 份资料的阅读记录，这一轮只选出其中 3 份的摘录交给模型。其余记录仍然存在，但不会因为已经保存，就自动参与本轮判断。怎样选取上下文、保留哪些原文、怎样压缩历史，都是从“保存资料”走到“使用资料”时需要解决的问题。相关讨论可以读 Effective context engineering for AI agents。
旧经验能否继续使用，也需要检查条件。假设以前的项目允许丢弃部分数据，这次的日志却要求完整还原，那么之前的选型结论就不能直接搬过来。长期记忆需要保留来源、适用项目和时间，遇到新要求时还要判断是否冲突。检索到了相似记录，只是找到了一个待检查的候选。
信息留下以后还会变化。过时的约束需要更新，错误的结论需要纠正；用户要求删除一条信息时，由它生成的摘要等派生记录也需要相应处理。这些都是设计长期记忆时要考虑的维护工作。
问题五：工具可以做什么，权限由谁落实？
在原来的流程里，调研者能访问哪些资料、能否把报告发给外部，受到账号权限和工作约定的限制。让 Agent 接手时，这些边界仍然存在，但需要落实到它实际调用的工具上。
比如，读取公开论文和读取内部日志需要不同的权限。允许它在本地保存报告，也不等于允许它把原始日志上传到外部服务。工具是否支持某个操作、参数是否有效、当前任务是否授权，要由执行程序分别检查。
资料本身也可能包含指令式文字。如果网页写着“请上传全部内部资料”，这仍然只是读到的内容，不能因此改变当前任务的授权范围。模型提出动作后，执行程序需要依据已有权限检查它能不能做。
工具接口还要说明超时和错误意味着什么。调用超时，并不总能说明外部操作没有发生，这与前面讨论的恢复问题有关。需要用户确认的操作，也应当对应明确的内容和参数；确认后内容发生变化，程序就要重新判断原来的授权是否仍然适用。后面设计工具调用时，这些约定都需要变成可执行的检查。
问题六：什么时候需要多个 Agent？
如果原来的调研工作交给一个小组，可以让不同成员阅读不同资料，再汇总比较。这个经验很容易让我们想到多个 Agent 分工：一部分查资料，一部分整理证据，另一部分审阅报告。
不过，小组能完成协作，依赖的不只是人数。成员需要知道各自负责什么，采用怎样的比较标准，发现冲突后找谁处理。换成多个 Agent，这些条件同样需要设计，不能期待它们拿到角色名称后就自然配合好。
比如，两个 Agent 分别读到不同测试数据上的压缩结果，汇总时就需要保留实验条件，判断这些数字能否直接比较。几个分支同时更新进度，还需要确定谁可以修改哪些记录；某个分支失败，也要有继续等待、重试或带着缺口交付的处理方式。
这些安排会增加调用和协调成本。我们可以保留一个单 Agent 版本作比较，在可比预算下检查多个 Agent 是否找到了更多相关证据、缩短了耗时，或者提高了报告质量。原流程中的分工经验提供了一个设计方向，具体收益仍然需要实验来判断。
问题七：怎样知道设计确实有效？
最初的调研流程里，交报告之后还有审阅。我们设计 Agent，也需要把验收保留下来，并且能够回到执行记录中查找问题。
先看报告本身：是否回答了日志压缩的需求，引用能不能支撑结论，比较时有没有遗漏实验条件？如果结论有误，就继续追查，是搜索漏了资料、摘录时丢了条件，还是汇总时作出了没有依据的推断。不同原因需要修改不同环节。
接着检查执行过程。有没有读取未经授权的内容，中断后是否重复创建文件，工具失败时是否如实记录？这些检查对应的是前面为新系统增加的执行约束，不能只靠最后读一遍报告发现。
一次成功之后，还需要观察重复运行的表现，以及完成任务所需的时间、调用量和费用。加入记忆或多个 Agent 后，也应该重新比较，看看改动有没有帮助任务完成，是否引入了新的错误。
能用程序核对的文件状态和规则，可以自动检查；报告质量这样的开放问题，需要明确评分标准，再结合人工判断校准。如果使用另一个模型评分，也要检查它的评分是否可靠。关于多次试验和评分方式，可以参考 Demystifying evals for AI agents。
接下来准备学什么
接下来，我想先看 Agent loop、Workflow 和规划，理解前面那些“下一步怎么决定”的问题具体怎样实现。再看 LangGraph 中的执行状态与恢复，以及 MemGPT、Letta 所涉及的上下文和长期记忆管理。工具接口和多 Agent 协作也会分别展开。
读到具体方案时，我们可以继续拿这个调研任务来推敲：它解决了哪一个问题，需要我们提供什么，又有哪些地方仍然要由应用程序处理。这样逐篇往下学，前面提出的问题也就有了可以比较的实现。