画智能体架构图很容易变成排方框：检索、分析、规划、写作、检查。一个方框一旦有了名字，就开始显得不可或缺。
但一种能力和一个独立模块，是两回事。某个任务需要访问历史证据，未必就需要一个单独的检索智能体；另一个任务可能要反复搜索；还有的任务，只使用当前材料也完全合理。
我的设计倾向是：把职责和边界说清楚，允许执行方式因任务而异。这是一种工程取舍，并不是说灵活的结构总会更快或更可靠。
执行流程会变，有些边界不变
假设两个任务共用同一个人的信息。一个写给家人的简短近况，另一个准备私人工作简报。
它们可能有相同的要求：只访问获准的来源，不偷看决策时刻之后的信息，不弄错一句话描述的是谁，如实报告失败。但它们不必采用相同的思考步骤，也不必得到同样多的上下文。
家人近况可能更需要考虑收信人知道什么。工作简报可能需要多轮检索与比较。强迫两者经过同一串智能体，可能增加了开销，却没有解决各自最难的问题。
真正值得复用的，也许是访问证据的接口或权限检查，而不是整套推理流程。
哪些需要明确，哪些可以随任务变化
| 需要明确的共同责任 | 取决于任务的选择 |
|---|---|
| 可以访问哪些来源 | 下一步查看哪个获准来源 |
| 决策的信息时间边界 | 是否值得继续寻找证据 |
| 允许的行动与预算 | 如何比较合格候选 |
| 保留证据与输出记录 | 使用多少上下文 |
| 如实报告完成与失败 | 是否表达一个非必需的观察 |
这只是一个起点。有些任务确实需要更严格的顺序约束，有些判断也不能放心交给智能体。重点是：这些限制应当由任务需要来解释，不能仅仅因为架构图上有这个方框。
从一个真实任务开始
我会先给智能体完成某个具体任务所需的工具、证据与边界，让它尝试，然后检查最早出现的真实失败。
如果它访问不到必要来源，就解决访问问题。如果它理解错了一句话，再加一层编排未必有用。如果它反复漏掉一个机械性约束，交给确定性代码强制执行可能更合适。这些问题需要不同的修复。
一种行为出现过一次，不足以成为围绕它建设永久模块的理由。先问，拿掉或替换这种行为，结果会不会改变。再问，换一个日期、任务或用户，它的作用还在不在。
晚一点抽象是有代价的：一些局部实现会重复，架构图也没那么整齐。但过早抽象也有代价：之后所有任务，都要继承那些只在第一个任务里成立、却从未在别处验证过的假设。
可复用的能力，不能只有一个名字
在把某项能力当作可复用资源之前，我想知道它需要什么输入和权限，观察到过什么贡献，有哪些已知失败，需要多少资源，以及什么情况下跳过它是合理的。
“理解用户”太宽泛，难以成为可执行的约定。“在当前用户的权限范围内，为一个存在争议的关系判断找到原始段落”，就具体得多。至于它应该实现成工具、嵌入某个步骤，还是交给独立智能体，仍然是实现上的选择。
反复使用，也不等于独立价值已经成立。一个组件可能出现在每次成功运行里，只是因为每次运行都被强制要求包含它。
公共层再薄，也可能藏着产品判断
一个很小的公共运行层，也可能悄悄替产品作决定。比如，一项看似机械的检查，开始规定什么才算有意思的生活事件，或所有人都应该收到什么情绪浓度的文字。
这些判断应该被明确摆出来。校验器能检查来源是否存在，但不能仅凭来源存在，就断定用户希望收到关于这件事的消息。
我希望公共层让任务中的决定可以被检查，并守住那些我们确实理解的边界。不能因为接口整齐，就把尚未验证的判断包装成通用规则。
一张有用的架构图，应该说清楚谁负责什么。它不应该变成所有后续智能体都必须照演的剧本。