护栏工程没有固定地址
护栏工程（Harness engineering）不是你软件栈中的某个位置，而是你代码的一种属性。
许多人认为护栏只是 AI 模型的一个包装层。这是错误的。护栏才是让模型在实际业务中发挥作用的关键。
我使用一个简单的公式：智能体 = 模型 × 护栏。
模型是引擎。护栏则是转向、制动和安全护栏。
但问题在于，模型在不断进化。每一个新的模型版本都在吸收护栏的部分功能。
- 推理模型现在可以处理思维链（chain-of-thought）逻辑。
- 更强大的模型可以原生处理工具调用（tool use）。
- 长上下文窗口正在取代旧的记忆系统。
如果模型“吞噬”了护栏，那你还剩下什么可以构建的呢？
会“融化”的部分是机械性的环节。循环、重试和记忆缝合（memory stitching）将变成通用化的组件。不要把职业生涯押注在构建“管道”上。
能够留存下来的部分是规范（specification）和验证（verification）。
- 规范：你必须定义智能体被允许执行的操作。模型无法了解你具体的退款政策或风险承受能力。这些逻辑存在于你的代码中。
- 验证：你必须证明智能体在规则范围内运行。模型无法可靠地自我评判。你需要一个外部层来检查工作成果。
想想一个退款智能体。
如果你把退款限额放在提示词（prompt）里，用户就可以诱导模型绕过它。如果你把限额写在代码的 if 语句中，模型就无法反驳。
那个 if 语句就是护栏工程。
护栏工程的核心在于两件事：
- 定义允许行为的边界（envelope）。
- 证明智能体始终在边界内运行。
模型是你正在控制的受控对象。 规范是你的目标。 护栏是控制器。 评估则是反馈。
工具和机械性环节每月都会变化，但规范与验证的学科逻辑不会。
停止构建“管道”。开始构建约束（constraints）和证明（proofs）。
Source: https://dev.to/saurav_bhattacharya/harness-engineering-has-no-fixed-address-2m7a
Optional learning community: https://t.me/GyaanSetuAi