从一个有边界的 Agent 开始

一张待办卡片上只写着“整理资料”。人能理解这句话后面的默认条件：整理哪一批资料、放进什么文件夹、什么时候停下来。交给 Agent 时，这些默认条件就需要成为设计的一部分。

这篇文章把问题缩到一个可以动手的小练习：做一个只处理个人公开书签的资料助手。它可以寻找、归类和起草摘要；正式发布仍由人决定。下面的结构是本站的 DIY 方案，不代表某个厂商的产品实现。

先画出一条能结束的路径

Anthropic 的设计文章区分了预先定义控制路径的工作流与由模型动态决定过程的 Agent。这是理解控制权的一个视角；文章发表于 2024 年，不能直接当作今天的 SDK 使用手册。

我的练习先采用一条固定路径：读取十条书签、提取页面标题、按主题建议分类、输出一份待检查清单。直到这个流程能够稳定结束，再考虑让模型自行决定是否继续检索。

flowchart LR
  A[十条公开书签] --> B[抓取与去重]
  B --> C[生成分类建议]
  C --> D[检查来源与格式]
  D --> E[人工确认后保存]

这里最值得写清楚的是结束条件。十条输入全部得到一种明确状态：已处理、页面不可访问、需要人工判断。没有拿到结果，也是一种需要被保留的结果。把失败悄悄从清单里删除，会让“完成率”失去意义。

给循环装上三个表

我会先定义任务表、行动表和证据表。任务表保存问题与完成标准；行动表保存一次次调用；证据表保存页面地址、抓取时间和支持结论的片段。三者可以先写进一个本地 JSON 文件，不需要一开始就选择复杂的框架。

再给循环设置预算。预算可以同时包含最多行动次数、最长运行时间、最多连续失败次数。它们解决不同的问题：次数限制防止空转，时间限制便于交互，连续失败限制避免把同一种错误反复重试。

type Budget = { steps: number; consecutiveFailures: number }
const budget: Budget = { steps: 12, consecutiveFailures: 2 }

while (!task.finished && budget.steps-- > 0) {
  const action = await proposeNextAction(task)
  const result = await executeAllowedAction(action)
  task = recordEvidence(task, action, result)
  if (needsHumanDecision(task)) break
}

这段代码是控制流程示意，函数需要自己实现。模型建议什么，和程序实际允许执行什么，是两份不同的数据。执行器应当检查允许的工具与参数范围，再把实际结果写回任务记录。

用两次小故障检查边界

第一次，让一个书签返回 404。观察助手会不会把缺失内容编成一段看似合理的摘要。第二次，把两条不同标题的书签指向同一个页面，观察去重后能否保留原始输入与合并理由。

如果系统只能在所有页面都正常的情况下工作，这个练习还没有完成。一个可用的资料助手，应该能够解释“这条为什么没处理”，而不只是展示处理成功的那几条。

给下一次改动留证据

每次修改提示词或工具描述后，都运行同一批书签，比较结果差异。暂时不要只看摘要是否更流畅；先看来源是否对应、失败是否被记录、行动有没有超出范围。最后把改动理由和一次完整运行记录放在一起。

这个小项目的第一份成果，可以是一张朴素的检查表。它不必拥有很多能力，但应该让下一位读代码的人知道：输入从哪里来，决定在哪里发生，结果凭什么可信。

继续阅读：从三十个反例开始做评估，以及把工具调用做成可恢复的工作。