“给订单系统加多租户。”
先别让 Agent 解释这句话，也别让它立刻拆成 12 个执行步骤。先把 goal 写成一句能判断完成与否的话：让不同客户的数据隔离，旧客户继续正常下单。
Agent 很快交出一份 12 步计划，内容包括选数据库、改表结构、加 tenant_id、补接口、迁移数据、写测试。看起来像项目经理突然长出了第二个显示器。
做到第九步，产品经理补了一句。有些客户的数据必须物理隔离，不能只靠字段过滤。
这时 Agent 通常不会停下来。它会先说一句“问题不大”，然后继续把第十步、第十一步写完。等数据库方案推倒重来，前面那 12 步已经变成一条装修得很精致的死胡同。
先把一句话写成 Goal
Wayfinder 是一个给 coding agent 用的长任务路线规划 Skill。它把目标、已知决策和还没弄清的问题放进一张能跨会话读取的地图，再逐张处理决策票据。我把上游的 /wayfinder Skill clone 下来，读完当前的 SKILL.md，再安装到项目里。这里说的 goal 模式，是对使用方式的概括，不是 Wayfinder 里多了一个按钮：先把一句话需求写成 Destination，再把路线不清、又装不进一次会话的工作放到那张地图上。
地图上先写 Goal，也就是 Destination，再写已经确定的决策；说不清的问题留在“未明确”区域。只有当一个问题已经能被准确描述，它才会变成一张决策票据。未知没有被 Agent 顺手填成“最佳实践”，所以还有机会在下一条事实出现后改路。
这比“请生成一份完整实施方案”多了一点诚实。后者像让实习生在需求评审前先把会议纪要、迁移脚本和庆功海报都做出来；Wayfinder 先把当前最该确认的那一件事挑出来。
换到十年老系统更换消息队列，先把 goal 写成“旧消费者可以并行，重复消息不会重复扣款”，而不是“换 Kafka”。前者是目的地，后者只是挑了一辆交通工具。
真正会改变路线的问题，可能包括失败重试由谁负责、旧消费者能否同时运行，以及消息重复时订单会不会被扣两次。
这些问题没有答案时，Agent 最应该产出的是一张票据，而不是一份“选型报告宇宙”。
会话级路线更新
Wayfinder 把当前开放、没有阻塞、还没人领取的问题叫作 frontier。一个 session 先认领一张票据，查代码、查文档、做小原型，再把答案写回地图；下一轮根据答案生成新的前沿。
这套节奏有点像导航重新规划。它不会因为已经播报过“前方右转”就坚持把车开进施工围挡，也不替人踩油门。官方安装下来的主件主要是一份指令文件，默认只做规划；路线清楚后，再交给 to-spec、to-tickets 和实现流程。小任务一场会话就能想清楚，没必要给它配一支参谋部。
所以，goal 模式的用法很朴素：先固定 Destination，再让每个 session 只解决通往它的一个问题。长任务最怕的，是导航已经改道，Agent 还在对着旧路线宣布“前方 200 米到达”。
