AI Agent 总是翻车？也许你缺的不是模型，是一个护栏

AI Agent 总是翻车？也许你缺的不是模型，是一个护栏

最近 AI 行业有个很有意思的现象：大家都在卷模型能力、上下文窗口、推理速度，但真正上生产环境的时候，最影响体验的往往不是模型不够强——而是 Agent 做事的方式太”野”。

一个 Agent 被扔进代码库，它可能会改错文件、跳过测试、幻觉自信地说”部署成功了”、或者在一个分支上卡了十分钟不汇报。这种时候，纯靠更强模型并不能根治。

Digital Stoic 的 pick-harness 解决的就是这个问题：不是让 Agent 更聪明，而是给它加护栏——而且告诉你加哪个最划算。

核心逻辑：按”延迟”选护栏，而不是按”高级程度”

这个 Skill 最反直觉的一个观点是：护栏好不好，不是看它有多 fancy，而是看它多早能拦住问题。

pick-harness 给出了一套决策框架，四个维度：

• 角色：是引导它（guide）还是观察它（sensor）？
• 性质：是代码/规则判断（computational）还是 LLM 自己判断（inferential）？
• 时机：事前拦（feedforward）还是事后纠（feedback）？
• 延迟：在生成 Token 之前就拦住，还是烧了 10 万 token 才报错？

核心原则一句话：越早拦住越好，最便宜的正确护栏，胜过最贵的复杂护栏。

举例：与其在 Agent 产出代码后花大成本做 LLM 审判，不如在编译阶段加一个类型约束——把 Seconds 和 Milliseconds 做成不同类型，一个 bug 类型直接变成编译错误，永久免疫。

工作流程：诊断 → 处方 → 脚手架

当你对 Agent 说”X 一直失败”或者”怎么防止它做 Y”，pick-harness 会：

• 先诊断：这个失败属于哪类护栏缺失
• 再处方：推荐最便宜/最早的护栏类型 + 说明理由
• 最后直接生成可粘贴的护栏代码

不是给你一堆理论，而是直接产出能跑的东西。

这个 Skill 解决的是什么问题？

行业里有个常见误区：Agent 出问题了，第一反应是”换更强模型”或者”加更多 Prompt”。但翻车的原因往往是系统层面的——Agent 没有边界、没有反馈、没有正确的拦截机制。

pick-harness 本质上是一个 Agent 工程的实用工具。它不是教 Agent 怎么做事，而是教运维 Agent 的人怎么设计它的”笼子”——让它的错误变得可控、可修复、代价低。

和它配套的还有两个 Skill：pick-model（选模型）和 pick-workflow（选拓扑结构），三者一起构成一个 Agent 部署前的决策三角。这三个 Skill 同属于 Digital Stoic 的 agent-skills 库，整体定位很清晰——做 Agent 工程的实用主义者。

使用方式

在 Claude Code 或任何支持 Skill 的 AI 工具里：

• 触发词：agent keeps failing at X、how do I stop it doing Y、what guardrail do I add
• 或者直接调用：/pick-harness

它会基于你的问题场景，返回具体的护栏建议 + 代码片段。

GitHub 仓库本身提供了完整的 HARNESS-ENGINEERING.md 参考文档，理论深度不低，但 Skill 本身的使用门槛很低——说人话，就是一个”Agent 出问题了？先看看缺哪个护栏”的速查表。

有意思的是，这个 Skill 的更新频率很高，最近一次是 2026 年 7 月 29 日。说明 Agent 护栏这个方向，社区正在快速积累经验。

https://github.com/digital-stoic-org/agent-skills

GitHub: https://github.com/digital-stoic-org/agent-skills