目标、说明与 Note 节点
解释 goal / brief / note 这类非执行节点怎么用。
这类节点最容易被低估，因为它们不一定直接执行。
但流程一旦复杂起来，真正决定能不能接手、能不能维护的，往往就是这些节点。
它们适合做什么
| 节点类型 | 更适合承担什么 |
|---|---|
| Goal / brief | 定义目标、边界、受众、成功标准 |
| Input / prompt | 明确输入字段、提示词、上下文 |
| Note | 留下不参与执行的说明、假设、handoff 信息 |
它们不适合做什么
- 真正的能力调用
- 数据整形
- 代替审批
- 把一大堆临时业务逻辑塞成说明文字
怎么配更好
- goal 节点里写目标，不写全部细节；
- prompt / input 节点里只放下游真的会用到的字段；
- note 节点用于人类阅读，不要假设 runtime 会替你理解一切；
- 如果某段说明必须影响执行，尽量结构化成输入，而不是只写在 note 里。
常见错误
- 把关键执行参数只写在 note 里；
- 把 note 当成 capability；
- 一个 brief 节点里塞了所有业务背景、规则、步骤和审批要求，导致无人可读。
建议用户怎么排查
如果流程老是“看起来对，但跑出来不对”，先检查：
- 关键输入是不是只留在说明节点里，没有真的传进执行节点；
- brief 是否过宽，导致下游节点一直在猜；
- note 是否承担了本不该由它承担的执行逻辑。