把午餐选择交给 Agent：点一张食物图片，子 Agent 去外卖平台下单，60–90 分钟后开饭
Colin（Bluesky 用户 colin-fraser.net，原帖作者本人；原帖显示名为 Colin）Bluesky · 2026-10-26
打开原帖来源文字 / 整理摘要
原帖全文（Bluesky，2026-10-26，本次经 Bluesky 公开接口取得，逐字）： “I had my AI agent create an app called “Lunch” to help me with decision fatigue and boost my productivity. It has a few pictures of things I might like to eat. Tapping one spawns a subagent to order that item on Uber Eats and 60-90 minutes later I’m eating. It’s 600 thousand lines of JavaScript.” 中文对照：他让 AI agent 做了一个叫 Lunch 的应用来缓解选择困难、提升效率；应用里有几张他可能想吃的食物的图片；点其中一张就会派生一个子 agent 去 Uber Eats 下这一单，60–90 分钟后他就吃上了；整个应用约 60 万行 JavaScript。
业务摘要
把「今天吃什么」从一个要翻外卖 App、比价、纠结十分钟的决定，压成一次点击：候选被固定成几张图，点下去就有子 agent 替你把这一单走完，人只负责在下单前看一眼金额和地址。它替代的是决策与操作的时间，不替代口味判断，也不该替代付款授权。
每天中午都在外卖 App 里刷十分钟、最后还是点昨天那家的人；想先验证「子 agent 能不能在真实网站上下单」的动手派；以及任何愿意把重复小额消费动作交出去、但坚持付款前停一次的人。
执行链路
- 先把「决定」和「下单」拆成两段
不要一上来就做自动下单。先把任务定义成两步：选出今天吃什么（人做一次点击），把这一单送出去（agent 做）。原帖的结构正是如此：点图是人的动作，派生子 agent 去 Uber Eats 下单是 agent 的动作。
- 候选集先写死，只放几张图
像原帖那样只保留几样你真的会吃的东西，图片与菜名一一对应，并写明规格（分量、辣度、不要什么）。候选集不固定，agent 就会每天给你换一批，选择困难只会更严重。
- 点图才派生子 agent，一次只派一个
一次点击只触发一个子 agent、只下一单，绝不做批量或定时自动下单。原帖描述的就是这种「点一次、派一个」的粒度，这也是把出错影响面控制在一顿饭之内的关键。
- 子 agent 只带最小信息去下单
交给子 agent 的只有：菜品名、规格、收货地址、金额上限。不要给它完整账号权限、不要让它自选店铺、不要让它顺手加购。信息给得越少，它跑偏的空间越小。
- 下单前停一次，人工确认
子 agent 找到对应商品后必须先输出一条待确认信息：店铺名、菜品与规格、实付金额、送达地址、预计时间。人点确认才允许提交订单。原帖没有讲这一层，但涉及真实付款就必须补上。
- 把每一单记成一条记录
确认下单后写一条记录：点击时间、下单时间、店铺、金额、预计与实际送达时间、结果。原帖只给了「60–90 分钟后吃上」这个体感区间，自己跑的时候要把它换成可核对的时间戳。
- 失败就退回手动，不要自动重试
店铺打烊、菜品售罄、地址不可用、超出金额上限，一律停下来把原因写清楚并交回人工，不做自动改单、不自动换店、不自动重试。一次重试就是一次可能的重复扣款。
复用方案
- 一个能派生子 agent 或调用外部动作的通用助手／自建 agent
- 外卖平台账号与可用支付方式，且你能接受把下单动作交给它
- 固定的收货地址与明确的单笔金额上限，先写死再开跑
- 头几次愿意在旁边盯着整个下单过程，逐项核对金额
- 接受失败：真实网站会改版、会售罄、会打烊，需要人工兜底
Prompt 指令
本站整理 · 未实测
你是一个点餐执行助手。目标是减少我每天中午做决定的时间。你可以选品和填单，但没有我的确认不能付款。 【输入】 候选清单（固定，最多 6 项）：[项名 | 规格 | 参考店铺或平台内关键词] 收货地址：[地址] 单笔金额上限：[数字，含配送费与小费] 平台：[外卖平台名称] 我本人负责：口味判断、最终付款确认 【执行步骤】 1) 把我点选的那一项和候选清单对齐，输出你要买的东西：项名、规格、平台内关键词。不要自己换项。 2) 在平台上检索该商品，只保留规格一致、评分与配送时间在可接受范围内的结果；找不到完全一致的结果就停下，不要挑最接近的替代。 3) 向我输出一条待确认信息：店铺名、菜品与规格、商品单价、配送费、实付合计、送达地址、预计送达时间。 4) 我回复确认后，才提交订单。提交后立刻回传订单号与预计送达时间。 5) 无论成功或失败，都写一条记录：点击时间、下单时间、店铺、实付金额、结果、失败原因。 【输出要求】 - 待确认信息：单行结构，字段为 店铺 / 菜品与规格 / 单价 / 配送费 / 合计 / 地址 / 预计送达。 - 下单结果：订单号、实付金额、预计送达时间。 - 失败说明：属于哪一种（售罄 / 打烊 / 地址不可用 / 超出上限 / 规格不一致），以及你停在哪一步。 - 记录：一条可追加的流水行。 【人工确认点】 - 没有我明确回复确认，不得提交订单、不得付款、不得加购、不得改地址、不得改支付方式。 - 合计超过我给的金额上限时，直接停下并说明超出多少，不得自行换便宜的替代。 - 一次点击只处理一单，不得批量下单、不得定时自动下单。 【失败与缺资料处理】 - 候选清单缺规格或收货地址为空时，不要猜，先问我。 - 平台检索不到、登录态失效、页面改版导致取不到价格，一律按失败报告，不得估算价格。 - 任何一步失败都不自动重试、不自动改单，不追加轮次，交回我处理。 【合成示例（非真实业务数据，仅演示格式；金额均为不带币种的合成数字）】 输入：候选第 2 项「番茄牛腩饭 | 大份、不要香菜」；地址「示例路 1 号 A 座」；上限 40 输出（待确认）：示例快餐（示例店） / 番茄牛腩饭·大份·不要香菜 / 28 / 5 / 33 / 示例路 1 号 A 座 / 预计 18:40 我确认后输出：订单号 A1B2C3，实付 33，预计送达 18:40，记录已写。
运行成本与避坑指南
成本：原帖未披露 token、费用或用量，采集站亦未给出。这类任务的成本主要来自浏览器操作步骤数与页面长度；本站不给未经核实的数字，建议先用一顿饭的单子估一次量。
运行条件：原帖给出的体感是从点击到吃上 60–90 分钟，其中大部分是商家出餐与配送，不是 agent 运行时间。真实下单受店铺营业时间、配送范围与平台登录态限制，夜间与高峰时段更容易失败。
避坑：最大的坑是把「点一下」直接接成「付一次款」：真实下单会花真钱，少了确认与上限就可能重复扣款或下错规格。第二个坑是候选集不固定，等于把选择困难原样搬进应用里。第三个坑是代码规模——原帖自嘲应用约 60 万行 JavaScript，说明这种看似简单的自动化搭起来并不轻。
示例与验证记录 · 合成示例
一次点选到下单的合成演示（非真实业务，未实际产生订单）
候选第 2 项「番茄牛腩饭 | 大份、不要香菜」；地址「示例路 1 号 A 座」；单笔上限 40；平台为示例外卖平台。
待确认：示例快餐（示例店） / 番茄牛腩饭·大份·不要香菜 / 28 / 5 / 33 / 示例路 1 号 A 座 / 预计 18:40 （人工回复「确认」后） 已下单：订单号 A1B2C3，实付 33，预计送达 18:40。 记录：10-28 17:52 点击 → 17:54 下单 → 33 → 成功。
