我不再让 AI 一把梭执行任务了：tri-action 的边界感-平芜编程栈

三个项目，三个翻车现场。上周我一口气让 AI「帮我把这事儿跑完」，结果没有一个善终。不是模型不够聪明，是我把「执行」这件事想得太轻了——以为只要把任务说清楚，Agent 自己就能又好又快办妥。

说白了，通用 Agent 一把梭最大的坑，是它分不清哪个操作能直接干、哪个操作干了就收不回。删库、发错消息、误触生产变更，这些事只要发生一次，你那点效率红利全赔进去都不够。

翻车不是偶然

我最早那套做法很朴素：把任务描述丢给 Agent，让它自己判断、自己调工具、自己收尾。听起来很美，第一次翻车在一个批量重命名的活儿上。我让它「把 logs 目录里带日期的文件整理一下」，它顺手把几个还在用的脚本也按规则改了名，CI 当场挂掉。你猜怎么着，它一句没跟我提，还是我在群里被测试同学 @ 才知道。

第二个更离谱。我让它「帮我把测试环境的配置同步到预发」，它读了描述，自作主张把生产数据库的连接串也一并改了。幸亏我们这边发布前还有二次确认，不然就是一晚上救火，我大概率得写事故复盘。

第三个是发消息。我让它「给上周提 issue 的几个用户回个简短说明」，它把草稿群发成了所有人可见的公开 @，还带了个我压根没写过的语气。我盯着屏幕愣了三秒，撤回都来不及，只能硬着头皮挨个道歉。

这三次我都在用同一个模式：语言指令 → 信任执行。问题不在模型能力，在于执行根本没有边界。

我试过的那些弯路

我试过在系统提示里写死「危险操作必须问我」。这玩意儿跟立规矩不写罚则一个样——模型心情好听一句，忙起来（或者它自认为忙起来）就跳过去了。软约束嘛，没有硬闸门兜着，全看它愿不愿意守。

我也试过把每一步都拆开人工点确认。跑下来发现跟我自己动手没区别，还慢三倍，纯纯的胶水流程。更别提有些任务本来就是长程多步的，逐步点头的体验烂到我想直接关掉对话。

我甚至想过干脆不让它执行、只让 AI 出方案。但有些活儿它就是得真跑，比如部署、定时清理、批量操作文件，光给方案不落地等于没说。出方案不执行和瞎执行，是两个极端，都不够用。

tri-action 把「执行」接住了

后来我把执行这块单独拆给 tri-action 管。它的逻辑跟通用「直接执行」不一样：它不是接到一句话就去调工具，而是先读 tri-intent 的快照，把意图认准是 I14（操作执行），再走一条固定链路——解析、校验、分级、确认门、执行、返回。意图识别这一步它自己不做，直接吃上游结论，所以不会临场重新理解你的需求。

关键在「分级」。tri-action 把每个操作按风险打到四个等级，这是我踩坑之后才觉得香的设计：

L0 只读：查数据、搜东西、读文件，不产生副作用，直接跑。
L1 可逆：建草稿、设提醒这种能撤的，直接跑。
L2 不可逆：删文件、提交表单、发消息，得先给你看操作清单和影响范围，你点头才动。
L3 高风险：资金交易、生产变更、批量删除，除了清单还得附不可逆说明和风险评估，确认过了才执行。

我当初特别讨厌那种「AI 默默把事办了还以为帮你省心」的设计。tri-action 反过来，L2/L3 不给你确认门它是不会动的，这是铁律。而且失败不擅自重试——这一点我踩过坑才懂，重复扣款、重复发送这种事，自动重试一次就够你喝一壶。不可逆操作失败后它只把原始错误甩回来问你，绝不自己再来一遍。

我用它落地一份执行清单大概长这样：

# .tribro/actions/I14_20260211_143022_6a5c037d/task.yamlintent:I14operation:action:delete_files# 操作动作target:"./logs/archive/*"# 操作对象tool:filesystem# 目标工具params:older_than:"30d"dry_run:falserisk_level:L2# 不可逆：删除confirm_gate:required:truechecklist:# 操作清单-"删除 ./logs/archive/ 下 30 天前的文件"-"影响范围：仅归档日志，不含活跃日志"irreversible_note:"删除后不可恢复，请确认路径无误"on_failure:auto_retry:false# L2 不擅自重试ask_user:true

这份清单一旦落到.tribro/actions/下，L2 的操作会先停在确认门这一步，把清单和影响范围甩给你看；你确认了它才真删。高风险的 L3 还会额外写一份 confirm-log.md，连内容哈希都算上，事后能审计是谁确认过、正文改没改过。对我来说这比「一句 prompt 约束」靠谱太多——它是流程级的硬闸，不是模型的心情。