AI 知识课程

Appearance

2.1 Agent 越界——约束（Constraints） ​

现象 ​

🔴 现象：Agent 总是"好心办坏事"

你明确告诉 Agent "不要修改 assert 语句"，它还是改了。

你写了"不要删除文件"，它删了。

你设置了"不要绕过安全检查"，它绕过了。

Prompt 里的规则，Agent 看到了，理解了，但不遵守。

这不是模型能力不足，而是指令本身就没有强制力。就像在纸上写"请勿入内"，大部分人不会进，但总有人会。

真实案例：assert true ​

一个经典案例来自实际生产环境：

⚠️无 Harness
🛡️有 Harness
test_payment.pyPython
1
assertpayment_amount>0,"金额必须为正"

Harness 解决方案 ​

方案一：Custom Linter——依赖方向检查 ​

用代码级别的规则，而非自然语言指令：

配置示例

yaml
# .linter-rules.yml
dependency-direction:
  # 支付模块可以依赖公共模块，反过来不行
  allowed:
    - payment → common
    - payment → models
  forbidden:
    - common → payment
    - models → payment

Agent 生成的代码如果违反依赖方向，Linter 直接报错——这不是建议，是拦截。

方案二：Linter + 修复指引 ​

不只拦截，还告诉 Agent 正确的做法：

拦截 + 引导 = 机制层面的"告诉它该怎么做"

yaml
assert-guard:
  pattern: "assert\\s+true"
  severity: error
  message: |
    检测到 assert true。如果你是因为测试不通过而修改断言，
    请修复业务逻辑而非测试代码。
    参考文档：/docs/testing-guidelines.md

方案三：CI 门禁 ​

在 CI 流水线中设置硬性门禁：

📤PR 提交
→
🔍Linter 检查
→
🧪测试运行
→
🔒安全扫描
→
✅合并
❌任一环节失败 → 自动回滚 + 通知

Agent 可以生成任何代码，但只要 Linter 或测试不通过，代码就进不了主干。

核心洞察 ​

🔴 核心洞察：机制可靠性 > 指令可靠性

指令（Prompt）是一种"建议"——模型可以选择遵守或不遵守。

机制（Harness）是一种"约束"——违反规则的动作根本无法执行。

与其写 100 行"不要做 X"，不如设 1 条规则让"做 X"不可能。

本节小结 ​

📌 本节核心要点

  • 现象：Agent 越界——明明写了规则却不遵守，修改 assert、删除文件、绕过安全
  • 根因：指令没有强制力，模型可以选择忽略
  • 方案：Custom Linter（依赖方向检查）、Linter + 修复指引、CI 门禁
  • 核心洞察：机制可靠性 > 指令可靠性，用约束替代说教

思考题 ​

  1. 在你的项目中，有哪些规则是通过 Prompt/"注释"来执行的？如果改成 Linter 或 CI 门禁，你首先会改造哪一条？
  2. "拦截 + 引导"比"纯拦截"好在哪里？如果只拦截不引导，Agent 会怎样？
  3. 思考"机制可靠性 > 指令可靠性"这个原则，它是否只适用于 AI？在人类团队管理中有类似的道理吗？

下一节预告 ​

约束解决了"不让 Agent 做错事"的问题，但 Agent 还有一个更隐蔽的问题——它不知道自己错了。

→ 下一节：Agent 不知道自己错了——反馈