一、先把任务变成可以检查的约束
假设用户要求给订单模块增加查询接口，系统可以在执行前，将用户的自然语言需求整理成结构化任务描述：
{ "goal": "新增订单查询接口", "allowed_paths": [ "src/main/java/com/example/order/**", "src/test/java/com/example/order/**" ], "forbidden_actions": [ "修改用户模块", "删除现有接口" ], "acceptance_criteria": [ "接口返回正确的订单信息", "订单不存在时返回规定错误", "原有订单测试全部通过" ]}这里不一定非要使用 JSON，核心是建立一个结构化的任务约束对象。
具体怎么实现？
用户输入自然语言后，可以通过单独的 LLM 调用，配合预定义的输出格式，将需求提取为结构化任务；也可以在 Agent 自身的规划阶段完成这一步。
但 LLM 提取的结果不一定正确，可能遗漏用户要求或错误理解限制，因此还需要进一步处理：
- 保留原始需求：保存用户原话，方便后续核对，避免只依赖模型生成的任务描述。
- 校验结构与约束：通过 Schema 检查字段和类型；对于明确的业务规则，通过后端代码进行校验。
- 落实关键权限：对于禁止修改的模块，结合项目配置确定实际文件范围，不能只依赖模型生成的路径。
- 处理不确定需求：如果无法可靠判断用户的真实意图，或者不同理解会导致明显不同的执行结果，就向用户确认。
二、用执行轨迹和自动化检查发现偏航
系统需要为每个任务维护执行记录，记录 Agent 做了什么、工具实际返回了什么，以及执行结果是否符合预期。
例如：
| 记录内容 | 示例 |
|---|---|
| 任务 ID | task-001 |
| 工具调用 | read_file |
| 工具参数 | OrderService.java |
| 实际结果 | 文件读取成功 |
| 后续操作 | edit_file |
| 验证结果 | Maven 测试失败 |
接下来根据不同问题，采用不同的检测方式：
| 问题类型 | 检测方式 |
|---|---|
| 修改了无关文件 | 使用 git diff --name-only 检查变更路径，与 allowed_paths 比较 |
| 引用了不存在的接口 | 检查实际代码、依赖定义，并运行编译 |
| 业务逻辑偏离需求 | 对照验收标准逐项检查，必要时交给独立 Reviewer |
| 产生事实幻觉 | 重新读取文件、查询真实数据或调用实际工具验证 |
| 测试失败 | 检查测试进程的实际退出状态和错误日志 |
例如，任务执行过程中可以检查 Git diff，任务完成后运行 mvn test。
需要注意：测试通过不代表业务需求一定满足，因此还需要结合业务验收标准进行检查。
三、在工具执行入口设置强制检查
发现问题之后再纠偏还不够，一些偏航应该在实际执行之前就被拦截。
对于 write_file、execute_sql 等可能产生副作用的工具，可以在执行入口检查：
- 权限检查：当前用户或 Agent 是否有权执行该操作。
- 资源范围检查：目标文件、数据表等资源是否在允许范围内。
- 操作类型检查：当前操作是否被禁止，例如删除文件或执行危险 SQL。
- 风险审批：对于高风险或无法可靠自动判断的操作，暂停执行并请求人工审批。
例如，Agent 尝试修改禁止修改的 UserService.java，执行器根据可信的项目配置发现目标路径超出允许范围，就拒绝本次写入，并返回明确的错误信息。
这里的关键是：allowed_paths 等限制必须由可信的后端规则或经过校验的任务状态提供，不能让模型自行决定是否绕过检查。
四、发现错误后，进行针对性纠偏
系统不应该简单地让 Agent 重新生成答案，而应该根据执行记录定位根因，再生成明确的修复任务。
例如，检测到以下问题：
- 修改了允许范围之外的
UserService.java。 - 新增接口引用了不存在的
UserRepository方法。 - 订单模块原有测试失败。
系统可以将这些错误反馈给 Agent，并要求其分析原因、给出修复计划，在约束范围内完成修复，然后重新运行测试。
但是，这条纠偏指令本身并不能保证 Agent 一定遵守要求。真正限制修改范围的，仍然是工具执行器的权限校验；真正判断测试是否通过的，应该是测试进程的实际执行结果。
同时，需要设置重试上限，例如最多允许 2 次自动修复。如果仍然失败，就停止自动执行并升级人工处理。
如果 Agent 已经修改了大量无关代码，应先保存 Git diff 和执行记录，再审查变更并决定是否回滚。不能不加区分地直接重置整个工作区，以免丢失用户原有的修改。
五、修复后必须重新验证
修复完成后，系统重新执行检查：
- 变更范围：是否只修改了允许的文件。
- 编译检查：是否存在编译错误。
- 单元测试：相关测试是否通过。
- 回归测试：原有功能是否受到影响。
- 需求验收：原始需求中的每一项要求是否满足。
只有必要的检查全部通过，才能将任务标记为成功；否则继续修复或转人工处理。
六、整体工程流程
自然语言需求 → 结构化任务 → 约束校验 → Agent 执行 → 记录执行轨迹 → 自动检查偏航 → 针对性纠偏 → 重新验证 → 验收结果。
核心原则： 不假设模型永远理解正确，而是通过轨迹发现问题、通过工具权限拦截违规操作、通过针对性纠偏修复错误，最后通过真实执行结果和验收标准判断任务是否完成。