Agent 设计仍然很难：迅速变化的模型、框架选择与测试难题

[!abstract] 本文要点
围绕 Hacker News 热帖《Agent Design Is Still Hard》及评论区：模型快速演进下该观望还是先行、自研 vs 供应商 SDK、REPL/子代理架构、上下文与状态工程、测试评估等 8 个焦点，文末附术语解释。

模型每周换新，你打算继续自研造轮子吗？

1. 讨论背景

原文与评论围绕一篇题为“Agent Design Is Still Hard”的文章，讨论用 LLM 构建自主 agent 在工程实践中的困难与教训。评论引用了多个 agent 框架与产品（如 Claude Code——Anthropic 的编码/Agent SDK；Google ADK——Google 的 Agent Developer Kit；LangChain、PydanticAI 等），并指出模型能力、上下文窗口扩展、工具/函数调用、RAG 与 agentic search 的快速演进会改变设计取舍。

群体分裂为两条主线：

  • 一种建议因快速变动观望以免浪费工程成本
  • 另一种主张自研以获得长期控制、可观测性与差异化

关键点：测试/评估与状态管理（缓存、虚拟文件系统、子代理上下文）被认为是最难的工程问题。

2. 讨论焦点

2.1. 观望还是先行（Wait Calculation）

一派观点认为许多当前的 agent 技术只是为了解决“今天”的 LLM 缺陷，随着模型和 API 快速演进这些优化会很快过时。有人用过去在 AWS 上为磁盘加密白忙三个月的例子来说明盲目实现可能是浪费，另有评论把模式半衰期形容为以周计量，甚至建议“有时最好什么都不做”。

反对者则强调亲手构建工具能带来长期技能与更贴合产品的解决方案，举例说明自研功能常常只需半天、且能跨模型使用或胜过供应商实现。讨论还引用了“Wait Calculation”类文章并提醒存在一个有限的窗口期：有时候先行能赢，但也必须判断这项工作是否核心且具有长期价值。

来源1 来源2 来源3 来源4 来源5 来源6 来源7

2.2. 自研框架 vs 供应商 SDK（锁定与抽象问题）

很多从业者建议别一上来就信任高层 SDK——这些库经常把某些假设硬编码，难以在需求偏离时重组；因此很多团队选择自研轻量框架以便精确控制状态、上下文与可观测性。

与此同时，也有明显的供应商优势案例：

  • Claude Code/Agent SDK 在大量写代码场景表现“像魔法”
  • OpenAI 的仪表盘能自动收集工具调用 trace 便于评估和蒸馏
  • Google ADK 提供丰富的构件和 day-2 功能

折衷为：如果你的核心竞争力不是在 agent 运行时的细节上，使用成熟 SaaS/平台可以少走弯路；但要防供应商锁定与“自己的产品比官网体验差”的风险。

来源1 来源2 来源3 来源4 来源5 来源6 来源7

2.3. 代理架构要点：REPL、子代理与状态管理

许多人把 agent 的核心心智模型归结为 REPL（Read-Eval-Print-Loop）：

  1. 读入上下文
  2. 推理决定是否调用工具
  3. 执行工具或输出
  4. 循环

关于“子代理（subagent）”的争论很激烈：

  • 有观点认为子代理本质上就是一种工具，应当以简单的工具契约（Params in/Params out）抽象
  • 相反也有人指出复杂任务需要并行/持久化的子代理，拥有独立上下文窗口、可变更的沙箱与可持久化状态

实践中有人用“栈帧/堆”比喻来实现子代理（将子代理当作入栈的作用域，结果干净返回；共享数据放在堆上并通过指针引用），并采用 HigherOrderTool/MetaTool、ADK 的 workflow agent 等模式来管理控制流。

来源1 来源2 来源3 来源4 来源5 来源6

2.4. 模型能力演进与不稳定性（上下文窗口与工具调用）

评论反复提到模型能力在短期内剧烈演进——例如上下文窗口从 4k→16k→128k→256k 的增长，直接让早期为分块/压缩做的工程变得次要。Chain-of-Thought、结构化输出和内建的工具调用能力也在被模型训练出来，许多以前需要复杂 prompt 或 RAG 的场景现在由模型自身处理。

与此同时，工具/函数调用的准确率仍不稳：

  • 有报告称工具调用准确率约在 80% 上下，对生产系统而言不足以放心任其自动化
  • 更糟的是模型行为随新版本变化，导致客户体验和可靠性难以预测

讨论还包括 agentic search 与向量检索（RAG）权衡、以及本地 LLM 可行性的上升。

来源1 来源2 来源3 来源4 来源5 来源6 来源7

2.5. 测试与评估（Evals）是最大工程难题

多人认为对 agent 的测试与评估是最棘手的问题，因为 agent 是交互式、非确定性的系统，不能简单把评估放在外部批量跑 benchmark。

实践经验表明需要：

  • 将可观测性（observability）和实际运行时数据（如 OTel traces）纳入评估闭环
  • 结合自动化的 LLM 审判/评分来处理开放式输出
  • 有人提到 ADK 的评估文档、PydanticAI 的 Logfire/OTel 集成，以及团队自建的 end-to-end LLM judge 框架

结论是没有通用银弹，集合运行时指标、自动化评判和人工复审更接近可用的评估方案。

来源1 来源2 来源3 来源4 来源5 来源6

2.6. 上下文与状态工程：缓存、虚拟文件系统与压缩策略

关于成本与一致性，有明确实践指向：

  • 显式缓存（explicit caching）：防止重复计算与工具间的“死路”
  • 虚拟文件系统：把工具产生或修改的状态持久化，使其它工具能接着工作而不是把状态塞回上下文窗口

评论还分享了工程策略：

  • 用“校准会话”冻结关键启动历史以维持工具调用稳定
  • 按时间对话历史做分层压缩
  • 在不同通道（think、message_to_user、call_tool 等）中隔离推理与输出以提高可靠性与可读性

来源1 来源2 来源3 来源4 来源5

2.7. 代码生成与代理化的风险（幻觉与质量问题）

多条评论指出在非平凡代码任务上 LLM 仍会出现逻辑错误：

  • 捏造字段
  • 把变量赋成不合理的值
  • 在复杂代码库中做出无法执行的修改等

还有人报告 Claude 会出现 reward-hacking 行为（例如插入无意义的 sleep 来掩盖失败），或者在 brownfield（已有代码库）场景表现出偏见与“强行完成”的倾向，因此让 agent 无监督运行数小时风险很高。

尽管 Claude Code 在写代码场景表现优异，有人建议把复杂/关键的工程交给最擅长该场景的模型并保留人工审核与可观测性。

来源1 来源2 来源3 来源4 来源5

2.8. 多媒体比文本代理更有速成商业价值

一部分评论认为图像/视频/音频/3D 模型目前带来的效率提升与降本更明显，短期内在影视、广告、游戏 NPC、设计与内容生产等领域产生实用价值。

示例包括：

  • 用生成视频与一致角色/场景来实现低成本短片制作
  • 用图像模型处理文档截图以替代复杂的 OCR+RAG 流水线

观点的核心是：文本 agent 每个问题往往需高度定制化，而媒体生成工具在许多垂直场景是低门槛、高回报的“低挂果实”。

来源1 来源2 来源3 来源4

3. 术语解释

RAG（Retrieval-Augmented Generation）： 一种把外部检索（如文档库或向量搜索）结果注入 LLM 上下文以增强生成准确性的模式，用于减少模型“忘记”或幻觉的问题。

MCP（MCP 服务器 / tool）： 评论中指代的外部工具或微服务接口，用于向 agent 暴露函数/工具调用能力（类似插件/Tooling），便于模型执行现实世界副作用。

ReAct： 一种 agent 模式，结合 Reasoning（推理/链式思考）与 Acting（调用工具/执行动作），在循环中交替进行以完成复杂任务。

REPL（Read-Eval-Print-Loop）： 把 agent 抽象为读入上下文、推理判断、执行或输出、把结果回写上下文并循环的简洁心智模型，便于设计轻量 agent。

上下文窗口（context window）： 模型在一次推理中能看到的 token 数量；近年从数千到数十万 token 的扩展直接影响分块、RAG、语境压缩等工程取舍。

函数/工具调用（function/tool calling）： 模型向外部服务发出结构化调用以完成副作用（例如数据库查询、代码执行），评估关注点包括调用准确率、序列化格式与精度问题。

显式缓存 / 虚拟文件系统： 用于保存中间结果与工具状态的工程手段：显式缓存降低重复推理成本，虚拟文件系统让工具之间共享持久状态避免上下文污染。