Agent 工作流设计：先做一次判断，再执行固定动作
你应该得到一张流程图和一个边界明确的执行约定：哪一段由代码完成、哪一段让模型判断、什么条件必须停止。没有在你的真实账户计时，就不承诺提速倍数。
适用场景让浏览器或电脑只执行可检查的有限动作
针对浏览器自动化慢、步骤重复的真实问题，设计一条能复用的固定流程。重点是可复用的判断→动作分界，不是更快的点击。
来源 · dex · @dexhorthy · X 原帖伴读
2026-09-21 · 编辑整理，未调用真实模型
背景 / 问题
Section titled “背景 / 问题”原帖讨论把工具调用拆成分类与行动。它与你做网页自动化时遇到的慢很相关：每次读取全页、重新找按钮、模型再思考一轮，会把已知的固定操作变成反复探索。
本教程不是让 Jev 替代 Playwright，也不承诺换模型就让网站秒开。我们先把时间分成模型、页面、网络和业务校验，再把只有少数模糊点的流程固定下来。
把「判断」从「执行」里提出来 固定流程 → 只问模糊点 → 有限路由 → 受控函数 → 回查实际结果
速度优化不删除权限和结果检查。
-
选择一个重复且低风险的流程，先只读，例如导出计划列表。
-
知道实际的账户、目标范围和成功标准。
-
保留页面或 API 的访问权限，不绕过登录、验证码或平台限制。
X 原帖配图，作者：dex · @dexhorthy。原帖链接保留；图像来自原作者发布内容，不代表本站实测。
1. 写出已经知道的动作，再标出真正不确定的地方
Section titled “1. 写出已经知道的动作，再标出真正不确定的地方”例如：打开授权页面、确认账户、选择日期、读取表格、保存文件。账号 ID 和日期范围可以确定性核对，不需要模型猜。
真正模糊的可能只有「这条异常属于可重试还是需要人工」。把它作为独立判断点，先不要让模型控制整条路径。
2. 定义有限选项，不让输入变成任意命令
Section titled “2. 定义有限选项，不让输入变成任意命令”允许结果可以是 process、ask_for_context、review、stop。每个结果只对应一段你事先批准的程序。
精确金额、权限、路径和预算校验留在代码里；不要把外部网页里的文本拼成 shell 命令，也不要由模型扩展自己的工具权限。
3. 固定执行路径，按业务条件等待
Section titled “3. 固定执行路径，按业务条件等待”脚本复用已经验证的元素定位或 API；按钮可用时继续，依赖新数据时等对应状态或响应，不到处加入固定几秒 sleep。
你仍然需要确认新筛选条件的数据已返回，而不只是按钮出现。账号变了、页面结构变了或写入结果不确定时停止，不盲目重试可能收费的操作。
4. 用完整计时与结果核对证明优化
Section titled “4. 用完整计时与结果核对证明优化”对同一任务记录模型往返次数、导航次数、外部请求时间、错误、复核和总耗时。速度比较必须同时保留成功判定与结果一致性。
第一次探索交给 Agent，之后重复工作交给固定脚本，失败再让人或模型帮助定位。这样得到的是可维护流程，而不是一串不可解释的坐标。
把耗时拆开，才知道应该优化哪里
这是测量设计，不是性能结果。记录每段起止与失败，有助于避免为了速度删掉重要校验。
| 阶段 | 测什么 | 是否主要靠换模型解决 |
|---|---|---|
| 页面导航 | 打开与数据就绪时间 | 通常不是 |
| 模型判断 | 请求与推理往返 | 可比较不同方案 |
| 执行校验 | 账户、权限、结果 | 不能跳过 |
| 人工复核 | 不确定结果处理时间 | 靠更清楚的工作流改善 |
不提供未经真实测试的耗时数字。
你应该得到一张流程图和一个边界明确的执行约定：哪一段由代码完成、哪一段让模型判断、什么条件必须停止。没有在你的真实账户计时，就不承诺提速倍数。
- 模型无法消除第三方网站的网络等待。
- 不要用强制点击和取消校验换速度。
- 收到「完成」后仍需回查业务结果。
- 你能说明输入来自哪里、哪些字段会参与处理。
- 你保留了原始记录及不确定、失败和人工修改的结果。
- 你能区分本地练习、作者演示与自己真实调用后的测试。
来源边界：依据所列公开来源整理；本站未复现演示。分类结果需人工复核，不会自动执行。
是不是所有步骤都应该用 Jev？
Section titled “是不是所有步骤都应该用 Jev？”不是。精确规则、授权和固定操作留在代码里，只在模糊判断处考虑模型。
MCP 换 CLI 一定更快吗？
Section titled “MCP 换 CLI 一定更快吗？”不一定。关键在于减少不必要的模型往返和重新探索，并测量真正瓶颈。