这里保存值得反复阅读的文章、文档与理念。每个链接后面记录原文要点、它与设计问题的联系，以及尚未想清楚的地方。随着重读和实践，这份索引会继续补充。
相关旧文也连接在各条目下，方便对照外部材料与本站已有的思考。关联说明会保留它们在问题、职责和适用场景上的差异。
原文要点与延伸思考分开记录；收录一篇文章，不代表赞同它的全部结论。
最近整理：2026-09-26
类型、约束与设计决策
Parse, don’t validate
原文：Parse, don’t validate · Alexis King · 文章
原文要点
检查一个列表非空，再返回普通列表，会丢失刚刚确认的信息。原文建议将输入解析成更精确的类型，例如非空列表，让后续函数可以直接依赖这个约束。解析仍会检查输入，但成功时会产出承载检查结果的数据。
延伸思考
这可以用来检查 Agent 工具的接口：参数通过检查后，是否仍以任意字符串或通用对象继续流转？如果执行层需要明确的资源标识或操作类型，可以在边界构造相应的数据。
但类型只能表达被建模的约束。一个有效的资源标识，不代表资源仍然存在，也不代表调用者此刻拥有权限。随时间变化的条件仍需在执行时检查。
关联旧文
- 《Structured LLM Design：按生命周期组织 Agent Runtime》提出，子调用先返回有明确类型的结果，再由程序决定如何验证、保存或合并。可以沿着这个结果交接点应用解析的思路：把已确认的条件表达在返回类型中，让调用者直接使用。具体能保证哪些条件，仍取决于类型的表达能力。
- 《Harness Engineering：模型之外的工程》区分能力、具体行动的权限与结果验证。这补充了类型设计的适用边界：工具参数合法，只回答了部分问题；操作是否获准、目标是否达成，还需要各自的判断依据。
继续追问
哪些检查结果值得成为类型的一部分？哪些约束依赖外部状态，无法通过一次解析长期保证？
可以对照 Orbit 的设计系统：两者都尝试通过限制可表达的选择，减少后续反复纠错。
Building an LLM safe design system
原文：Building an LLM safe design system · Polar · 文章
原文要点
Polar 在 Orbit 中尝试使用有类型的组件属性、表达用途的设计 token 和 CI 规则，减少生成代码绕过既有设计决策的机会。文章将这套系统描述为仍在探索的方案。
延伸思考
它与 Parse, don’t validate 有一个相近的出发点：把已经确定的约束放进接口，让调用者使用这些决策。两者并不等同；类型约束与 lint 规则能够覆盖的范围不同。
文章对 CI 通过的信任需要限定范围。自动检查只能验证已编码的规则，不能据此推断布局、可访问性和交互体验全部正确。设计系统还需要允许有理由的扩展，否则一致性也可能成为表达新需求的障碍。
关联旧文
- 《代码库的文化与智能编程代理的使用范式》讨论代理如何模仿并放大已有范例。Orbit 提供了一个具体对照：把希望延续的设计决策放进组件接口和检查规则。旧文同时提醒，哪些范例值得复制、哪些标准值得执行，仍需要工程判断。
- 《Model Ergonomics：Harness 如何影响 Agent 能力》关注接口如何影响模型选择行动、生成参数和恢复错误的难度。可以据此检验 Orbit 的接口：语义化属性是否减少了无关选择，是否更容易正确使用？有限选项带来的收益仍需验证，不能只从接口看起来更整齐得出结论。
继续追问
哪些设计选择应该封装成有限选项？出现合理的新需求时，如何扩展系统，同时避免恢复到任意取值？
意图与交互
Intent by Discovery: Designing the AI User Experience
原文：Intent by Discovery: Designing the AI User Experience · Jakob Nielsen · 文章
原文要点
Nielsen 将意图描述为期望结果、约束和委托边界的组合。他提出，AI 交互还应帮助用户通过比较备选方案逐渐发现目标，并保留检查、修正与接管工作的界面。
延伸思考
设计 Agent 产品时，可以区分两个阶段：目标尚不清楚时，提供可比较的具体方案；目标已经明确时，让用户检查计划、权限和执行结果。重复追问抽象偏好，未必比展示两个候选结果更有效。
文章中关于未来界面形态的描述属于作者的判断与预测。对于目标固定、操作频繁的任务，直接操作仍可能比委托更省力。是否采用意图界面，应看任务和纠错成本。
关联旧文
- 《当表情成为界面：关于一个情绪生成空间的设想》描述了一个反馈循环：人的动作改变环境，环境的回应又改变人的下一次尝试。这可以帮助思考意图如何在交互中逐渐形成。不过，那篇文章探索的是艺术体验，也允许“误读”成为作品的一部分；执行受委托任务的 Agent，仍需让人检查目标是否被正确理解。
- 《不是替他们设计人生：公益中的“非设计之设计”》提供了另一个关于设计权的视角：改善行动条件，让参与者能够表达、协商和修改方案。把这个问题带回 Agent 界面，就可以追问用户是否仍能修改目标、拒绝系统的假设和撤回委托。这里借用的是对选择权的关注，公益服务与软件委托的责任关系仍需分别分析。
继续追问
怎样区分“用户还不知道自己要什么”和“系统没有理解已经说清的需求”？什么时候展示方案，什么时候直接执行？
Agent 的组织与记忆
大规模编排 AI 代码审查
原文：大规模编排 AI 代码审查 · Ryan Skidmore · Cloudflare · 文章
原文要点
Cloudflare 将代码审查拆给职责明确的专业审查器，再由协调器去重、筛除误报并汇总结果。文章强调同时说明应检查和应忽略的内容，并用结构化结果连接后续流程。
延伸思考
这个案例值得用来思考 Agent 的责任分工：每个角色应提供什么证据，谁判断问题是否成立，谁决定最终动作。只增加角色数量，不能自动提高判断质量；多个角色也可能共享同一种误解。
采用类似设计前，需要比较它与单个审查器的实际效果，包括误报、漏报、延迟和维护成本。复杂编排是否值得，应由这些结果决定。
关联旧文
- 《让 Gate 看见过程：LLM Agent 开发中的观察、契约与诊断》区分决定成败的契约、描述过程的观察，以及证据能支持多具体的结论。这为审查系统提出了一个要求：发现问题时保留依据，证据不足时保留不确定性，让后续修改能落到有证据支持的范围内。
- 《Structured LLM Design：按生命周期组织 Agent Runtime》从并发任务的所有权补充这个案例：谁等待子审查器，谁传播取消，谁收集并提交结果？其中“完成顺序不应自动成为会话顺序”的原则，也可以用来审视多路审查结果的汇总。这是分析案例的视角，并不表示 Cloudflare 的实现已经满足这些约定。
继续追问
协调器否定一条发现时，是否保留了可检查的理由？怎样识别多个审查器都没有发现的问题？
Observational Memory
原文：Observational Memory · Mastra · 文档
原文要点
Mastra 的 Observational Memory 使用 Observer 从交互历史中提取观察记录，再由 Reflector 整理与压缩这些记录。达到相应条件后，较早的原始消息会被观察记录替换，以控制进入上下文的信息量。
延伸思考
这提供了一个观察记忆设计的角度：记忆需要有选择、有更新，也需要处理遗忘。但压缩本身不保证保留下来的内容正确或充分。偏好、任务进展和外部事实，可能需要不同的更新与失效规则。
如果一条摘要会影响后续动作，应考虑保留它的来源和时间，以便重新检查。这里的来源追溯是延伸的设计问题，不表示这份文档已经完整解决它。
关联旧文
- 《从工具调用到事件驱动：大语言模型智能体的运行时架构》同样强调先筛选信息，再交给模型，但这里有两个不同的观察职责：旧文中的 observer 从运行时变化中提取值得重新决策的信号；Mastra 的 Observer 从历史交互中形成后续可用的记忆。两者可以配合，不能仅因名称相同就视为同一个模块。
- 《Structured LLM Design：按生命周期组织 Agent Runtime》区分模型当前可见的 context 与程序保存的状态，并用临时总结说明局部计算的结果不必自动写回原会话。这为记忆压缩补上了保存边界的问题：哪些内容进入下一次模型输入，哪些留在程序中，谁决定摘要是否替换旧内容？缩短上下文并不要求同时删除可供回溯的原始记录。
继续追问
哪些信息可以丢弃，哪些信息必须能回到原始记录？用户后来纠正的事实，怎样替换已经进入记忆的旧说法？
这是一份持续更新的产品文档；具体配置和实现行为应以使用时的原文为准。