一、引言：边界的重要性
当 AI Agent 能够编写代码、修复 Bug、甚至设计架构时，一个根本性的问题浮现出来：
我们应该让 AI 做到什么程度？边界在哪里？
边界过宽，可能导致失控、质量下降、甚至伦理风险。边界过窄，又无法发挥 AI 的潜力。
找到这个边界，是 Harness Engineering 成功的关键。本文将探讨人机协作的边界问题。
二、边界的维度分析
2.1 四个关键维度
┌─────────────────────────────────────────────────────────┐
│ 人机边界的四个维度 │
├─────────────────────────────────────────────────────────┤
│ │
│ 维度 1：任务复杂度 │
│ 简单 ───────────────────────────────────────→ 复杂 │
│ 代码补全 函数生成 模块开发 系统设计 架构决策 │
│ ↑ ↑ ↑ │
│ Agent 协作 人类 │
│ │
│ 维度 2：风险等级 │
│ 低风险 ─────────────────────────────────────→ 高风险 │
│ 工具函数 业务逻辑 核心算法 安全模块 金融交易 │
│ ↑ ↑ ↑ │
│ Agent 协作 人类 │
│ │
│ 维度 3：创造性需求 │
│ 常规 ───────────────────────────────────────→ 创新 │
│ CRUD 业务流程 交互设计 技术突破 颠覆创新 │
│ ↑ ↑ ↑ │
│ Agent 协作 人类 │
│ │
│ 维度 4：伦理敏感性 │
│ 中性 ───────────────────────────────────────→ 敏感 │
│ 内部工具 用户界面 推荐算法 隐私数据 生命决策 │
│ ↑ ↑ ↑ │
│ Agent 协作 人类 │
│ │
└─────────────────────────────────────────────────────────┘
2.2 边界决策矩阵
场景
复杂度
风险
创造性
伦理
建议
日志工具函数
低
低
低
中性
Agent 自主
API 接口开发
中
中
低
中性
Agent 主导，人类审查
用户认证系统
中
高
低
敏感
人类主导，Agent 辅助
推荐算法
高
高
中
敏感
人类设计，Agent 实现
新产品架构
高
高
高
中性
人类主导，Agent 验证
医疗诊断系统
高
极高
高
极敏感
人类决策，Agent 辅助
三、应该交给 Agent 的任务
3.1 适合 Agent 的特征
┌─────────────────────────────────────────────────────────┐
│ 适合 Agent 的任务特征 │
├─────────────────────────────────────────────────────────┤
│ │
│ ✓ 明确的目标和验收标准 │
│ └── "实现一个计算斐波那契数列的函数" │
│ │
│ ✓ 有限的上下文和依赖 │
│ └── 修改范围可控，影响面清晰 │
│ │
│ ✓ 可自动验证的结果 │
│ └── 有测试用例可以验证正确性 │
│ │
│ ✓ 重复性高、模式化 │
│ └── CRUD、数据转换、模板代码 │
│ │
│ ✓ 容错性高，可回滚 │
│ └── 失败影响小，可快速恢复 │
│ │
│ ✓ 有大量历史示例 │
│ └── 代码库中有类似实现可供参考 │
│ │
└─────────────────────────────────────────────────────────┘
3.2 Agent 擅长的具体任务
类别
具体任务
自动化程度
代码生成
工具函数、数据模型、API 接口
90%+
测试生成
单元测试、边界条件、Mock 数据
85%+
代码重构
变量重命名、函数提取、格式调整
95%+
文档生成
API 文档、代码注释、使用示例
80%+
Bug 修复
常见错误、安全漏洞、性能问题
70%+
依赖更新
版本升级、兼容性修复
75%+
四、应该由人类决定的任务
4.1 必须人类主导的特征
┌─────────────────────────────────────────────────────────┐
│ 必须人类主导的任务特征 │
├─────────────────────────────────────────────────────────┤
│ │
│ ✗ 涉及重大商业决策 │
│ └── "是否应该进入这个市场？" │
│ │
│ ✗ 影响用户权益和隐私 │
│ └── "如何收集和使用用户数据？" │
│ │
│ ✗ 存在伦理和社会影响 │
│ └── "算法是否会造成歧视？" │
│ │
│ ✗ 需要创造性突破 │
│ └── "如何设计下一代产品架构？" │
│ │
│ ✗ 后果不可逆或难以挽回 │
│ └── "数据库迁移策略" │
│ │
│ ✗ 涉及多方利益协调 │
│ └── "团队资源分配" │
│ │
└─────────────────────────────────────────────────────────┘
4.2 人类必须主导的具体场景
场景
原因
人类角色
架构设计
影响长期发展，需要权衡多方因素
设计决策
技术选型
影响团队能力栈，有长期绑定效应
评估选择
安全策略
涉及风险承担，需要责任主体
制定审核
数据治理
涉及合规和伦理，需要人类判断
规则制定
产品方向
涉及用户需求理解，需要洞察力
需求定义
危机处理
需要快速综合判断，担责决策
指挥协调
五、协作区域：人机共同决策
5.1 协作的最佳模式
┌─────────────────────────────────────────────────────────┐
│ 人机协作的四种模式 │
├─────────────────────────────────────────────────────────┤
│ │
│ 模式 1：人类决策，Agent 执行 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 人类：确定技术方案、接口设计、算法选择 │ │
│ │ Agent：编写实现代码、生成测试、编写文档 │ │
│ │ 适用：中等复杂度任务，方案明确 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 模式 2：Agent 建议，人类决策 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent：生成多个方案，分析优缺点 │ │
│ │ 人类：评估选择，确定最终方案 │ │
│ │ 适用：需要创造性或权衡的决策 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 模式 3：迭代协作 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 人类：提出初步想法 │ │
│ │ Agent：扩展完善，生成原型 │ │
│ │ 人类：评审反馈，指出问题 │ │
│ │ Agent：修改优化 │ │
│ │ ... 多轮迭代 ... │ │
│ │ 适用：探索性、创新性任务 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 模式 4：监督执行 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent：自主执行，实时汇报进度 │ │
│ │ 人类：监控关键节点，必要时介入 │ │
│ │ Agent：遇到边界情况请求指导 │ │
│ │ 适用：长时运行任务，需要持续监督 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
5.2 协作中的责任划分
责任
人类
Agent
说明
目标设定
✅
❌
人类确定要做什么
方案选择
✅
建议
人类最终决策
执行实现
监督
✅
Agent 具体执行
质量验证
抽查
✅
Agent 自动验证
结果承担
✅
❌
人类承担最终责任
持续改进
✅
✅
共同优化
六、边界的动态调整
6.1 信任的建立过程
┌─────────────────────────────────────────────────────────┐
│ 信任建立的四阶段 │
├─────────────────────────────────────────────────────────┤
│ │
│ 阶段 1：怀疑（Doubt） │
│ ├── Agent 能力有限，错误率高 │
│ ├── 人类全程监督，逐项审查 │
│ └── 边界：Agent 只能做最简单任务 │
│ ↓ 通过积累成功案例 │
│ 阶段 2：试探（Trial） │
│ ├── Agent 能力提升，错误率降低 │
│ ├── 人类抽样审查，关键节点确认 │
│ └── 边界：Agent 可以做常规任务，复杂任务需审批 │
│ ↓ 持续验证可靠性 │
│ 阶段 3：信任（Trust） │
│ ├── Agent 表现稳定，可预期 │
│ ├── 人类关注结果，过程自主 │
│ └── 边界：Agent 可以自主完成大部分任务 │
│ ↓ 长期稳定表现 │
│ 阶段 4：委托（Delegate） │
│ ├── Agent 成为可靠伙伴 │
│ ├── 人类设定目标，Agent 自主规划 │
│ └── 边界：Agent 可以处理复杂任务，人类关注战略 │
│ │
│ 关键：边界随信任度动态调整，不是一成不变 │
│ │
└─────────────────────────────────────────────────────────┘
6.2 边界调整的策略
信号
解读
调整策略
Agent 成功率高
能力被验证
逐步扩大边界
人工审查发现大量问题
能力不足
收紧边界，加强培训
出现严重事故
边界过宽
立即收紧，复盘改进
人类成为瓶颈
边界过窄
适当放宽，提升效率
新场景出现
未知风险
谨慎试探，逐步放开
七、伦理与责任
7.1 核心伦理原则
┌─────────────────────────────────────────────────────────┐
│ AI 工程伦理原则 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. 人类最终责任原则 │
│ └── 无论 Agent 做什么，人类承担最终责任 │
│ │
│ 2. 透明可解释原则 │
│ └── Agent 的决策应该可被理解和审计 │
│ │
│ 3. 公平无偏见原则 │
│ └── 防止 Agent 学习并放大人类偏见 │
│ │
│ 4. 隐私保护原则 │
│ └── Agent 不应滥用用户数据 │
│ │
│ 5. 安全可控原则 │
│ └── 确保 Agent 行为在可控范围内，可紧急停止 │
│ │
│ 6. 持续监督原则 │
│ └── 即使高度信任，也不完全放任 │
│ │
└─────────────────────────────────────────────────────────┘
7.2 责任归属框架
场景
责任主体
说明
Agent 按规范执行，结果正确
人类（设计者）
设计良好的 Harness
Agent 按规范执行，结果错误
人类（验收者）
验收把关不严
Agent 违反规范执行
Agent / 系统
系统缺陷，需改进
人类 override Agent 导致错误
人类（决策者）
人类承担责任
边界模糊导致事故
组织 / 管理者
边界定义不清
八、实践建议：如何设定边界
8.1 边界设定 checklist
□ 明确任务的目标和验收标准
□ 评估任务的复杂度和风险等级
□ 确定可自动验证的质量指标
□ 定义人工审查的关键节点
□ 建立紧急停止和回滚机制
□ 明确责任归属和升级路径
□ 设定边界调整的触发条件
□ 建立持续监控和反馈机制
8.2 不同组织的边界策略
组织类型
风险偏好
建议边界策略
初创公司
高风险容忍
边界较宽，快速迭代，快速学习
成长公司
中等风险
边界适中，核心系统保守，外围系统开放
大型企业
低风险容忍
边界较窄，渐进试点，严格治理
金融机构
极低风险
边界严格，强监管，人类终审
政府机构
极低风险
边界极严，透明审计，全程留痕
九、未来展望：边界的演进
9.1 边界扩展的趋势
时间
Agent 能力
边界变化
现在
代码生成、简单修复
常规编码任务
2-3 年
复杂重构、系统设计
架构级任务
5 年
创新设计、自主优化
创造性任务
10 年+
？
？
9.2 不变的原则
无论边界如何扩展，以下原则始终成立：
人类始终是目标的设定者
人类始终是责任的承担者
人类始终是价值的判断者
十、结语：找到你的边界
Harness Engineering 的边界不是固定的，而是根据场景、信任度、风险偏好动态调整的。
关键是：
- 理解边界的重要性
- 建立边界的评估框架
- 在实践中不断调整优化
- 始终保持人类的最终控制
找到适合你的边界，让 AI 成为最好的伙伴，而不是替代品或威胁。
参考与延伸阅读
- Human-in-the-Loop Machine Learning - Robert Monarch
- AI Ethics - Mark Coeckelbergh
- Responsible AI - Microsoft
