Agent 产品越热，越要讨论一个不太热闹的问题：系统什么时候应该停下来。
今天的 AI 新闻集中指向安全与自动化边界。欧洲央行提醒银行准备 AI 辅助网络攻击，日本三大银行将获得 Anthropic Mythos 访问权限，OpenAI 也向欧洲企业开放新的网络安全模型能力。另一边，Google I/O 前夕，Gemini、AI Mode、Android 与各种 Agent 能力继续成为关注焦点。看起来两条线不同，其实都在问同一件事：当 AI 开始参与真实流程，系统如何控制风险？
很多新手看 Agent 演示，会被“自动完成任务”吸引。打开网页、搜索信息、点击按钮、填写表单、提交结果，整个流程像一个自动工作的实习生。但真实产品不是演示视频。页面结构会变，按钮文案会变，弹窗会遮挡，登录态会失效，网络会超时，表单会校验失败。更重要的是，有些按钮不是普通按钮，而是发送、支付、删除、提交、修改配置。
所以 Agent 产品的第一原则，不是尽可能自动，而是先定义动作风险。
可以先把动作分成三类。低风险动作包括读取页面、摘要正文、提取字段；中风险动作包括填写表单、生成邮件草稿、整理候选方案；高风险动作包括发送邮件、提交订单、删除数据、修改权限、触发财务流程。低风险动作可以自动执行，中风险动作需要用户确认，高风险动作默认停下来。
工程上可以写成简单结构：
type AgentStep = {
action: 'read' | 'extract' | 'draft' | 'fill' | 'send' | 'submit' | 'delete';
risk: 'low' | 'medium' | 'high';
needConfirm: boolean;
reason: string;
};
这段结构的意义不是代码多复杂，而是把“能不能执行”从模型回答里拿出来，放进系统规则里。模型可以建议下一步，但系统必须判断是否需要确认。
第二个关键是日志。Agent 每一步看到什么、计划做什么、执行了什么、失败原因是什么、是否经过用户确认，都应该留下记录。没有日志，出错后无法复盘；没有复盘，就无法改进；无法改进，用户就不会信任。
第三个关键是缺失信息处理。一个可靠 Agent 应该敢于说“不够”。网页没有发布时间，就不要编一个；表单字段不明确，就不要猜；用户目标涉及付款或删除，就先停下来。会停的 Agent，比自信乱点的 Agent 更接近真实产品。
如果要做一个新手项目，不建议上来做万能浏览器 Agent。更好的起点是网页摘要助手。用户输入链接，系统抓取正文，清洗广告和导航，然后输出标题、摘要、关键点、缺失信息和来源。这个项目没有高风险动作，但已经训练了 Agent 最重要的能力：读取、清洗、生成、校验和确认。
多模型测试也可以放在这里。一个模型负责正文摘要，一个模型检查缺失信息，一个模型判断是否存在风险动作。需要集中比较不同主流模型在任务拆解、结构化输出和风险识别上的表现，可以把 gpt985.com 作为多模型入口。对 Agent 开发来说，真正有价值的不是“哪个模型最会说”，而是哪个模型在边界场景里更稳。
掘金读者关心的是落地。一个 Agent 系统至少要有四个模块：任务规划、动作执行、风险策略、审计日志。很多 Demo 只有前两个，所以看起来很聪明，实际上不可靠。生产环境需要后两个，否则系统越自动，风险越不可控。
Agent 产品还要设计失败路径。抓取失败怎么办？JSON 解析失败怎么办？页面正文不完整怎么办？用户要求发送邮件但缺少收件人怎么办？模型无法判断风险怎么办？这些问题如果没有处理，系统迟早会在真实任务里出错。
今天的 AI 安全热点说明，AI 能力会继续增强。能力增强不代表系统可以少设计边界，恰恰相反，能力越强，边界越要清楚。一个能自动执行十步但无法解释的 Agent，不如一个只执行三步但每一步都能确认和回滚的系统。
如果把这个思路放进真实 Agent 产品，第一版不应该追求万能，而应该追求可验证。比如做一个网页资料整理助手，只允许它读取网页、提取正文、生成摘要、列出缺失信息。它不能点击购买，不能提交表单，不能发送邮件。这样虽然不炫，但可控。
第二版可以加入表单草稿能力。用户提供背景信息，Agent 生成一份草稿，并标注哪些字段来自用户输入、哪些字段是模型整理、哪些字段需要人工补充。这里仍然不自动提交，因为提交意味着真实后果。
第三版才考虑有限执行，比如把用户确认后的草稿填入表单，但最终提交按钮仍然由用户点击。这个设计看起来慢，却能建立信任。用户知道系统不会越过自己做决定，开发者也能把风险控制在可测试范围内。
很多 Agent 产品失败，不是模型能力太差，而是产品一开始就承诺太多。它想读页面、理解目标、规划步骤、填写信息、提交结果，还要处理所有异常。结果一旦页面结构变化、字段缺失、登录过期，就会失控。更稳的路线是把能力拆开：先读稳，再写稳，再确认稳，最后才谈执行。
Agent 的评估也不能只看成功演示。要准备异常测试集：正文缺失的页面、按钮文案变化的页面、弹窗遮挡的页面、需要登录的页面、模型输出 JSON 缺字段的情况。真正可靠的系统，不是在一个演示页面上跑通，而是在异常情况下知道停下来。
如果要进一步产品化，还需要把风险策略做成配置，而不是写死在提示词里。比如 submit、delete、payment、send 这些动作永远需要用户确认；涉及客户资料、账号权限、财务金额的任务需要二次确认；模型无法输出结构化结果时，系统必须回退到人工处理。提示词可以提醒模型，但最终约束必须由系统执行。
这也是 Agent 和普通聊天机器人的区别。聊天机器人答错了，用户可以不采用；Agent 一旦执行错误，就可能发出邮件、提交订单、删除资料。越接近真实动作，越不能把安全交给模型自觉。
如果把这个思路做成产品原型，可以先从三个页面开始测试。第一类是普通文章页，检查 Agent 能否只提取正文，不把广告和评论混进摘要。第二类是表单页，检查 Agent 能否生成草稿但不自动提交。第三类是账户设置页，检查 Agent 能否识别修改权限、删除数据、发送通知这些高风险动作，并强制停下来。
每一类页面都应该有失败用例。文章页没有发布时间怎么办？表单字段缺少必填信息怎么办？账户页出现二次确认弹窗怎么办？模型输出不是合法 JSON 怎么办？这些场景比演示成功路径更能说明系统是否可靠。
开发者还可以给 Agent 设计一个最小审计日志：任务目标、页面地址、模型计划、动作列表、风险等级、用户确认结果、失败原因。日志不需要一开始很复杂，但必须存在。否则用户说“它刚才点错了”，开发者根本不知道系统当时看到了什么、计划了什么、执行了什么。
真正可上线的 Agent，不是从一开始就替用户做所有事，而是先替用户整理信息、生成候选、提醒风险，再在明确确认后执行低风险动作。这个顺序越稳，后面扩展越安全。
最后，如果你正在做 Agent 或自动化产品，不要先追求全自动。先做可验证的小助手，再逐步增加能力。需要集中体验主流模型在结构化输出、任务拆解和风险判断上的差异时，可以用 gpt985.com 作为入口，把同一个 Agent 场景交给不同模型测试。真正可靠的 Agent，不是替用户乱点网页，而是在明确边界里帮用户完成可验证任务。
