7.2 常见误区与开放问题
知道了正确的方向，也要知道哪些路是错的。本节列举 5 个最常见的误区，以及 6 个尚未有定论的开放问题。
五大常见误区
误区 1预先设计完美 Harness
❌ 错误认知在项目开始前，花大量时间设计一个"理想的" Harness 架构
为什么错Harness 是伴随项目演进的。无法预判 Agent 会在哪些地方犯错，只有真正跑起来才知道哪里需要补偿
✅ 正确做法从最小可用的 Harness 开始，根据实际观察逐步补全。先跑起来，再迭代
误区 2安装几十个 Skills / MCPs
❌ 错误认知越多工具越好，把市面上的 Skills 和 MCPs 都装上
为什么错增加 Agent 决策复杂度、工具冲突、调试难度指数级增长
✅ 正确做法只装当前任务真正需要的工具。3-5 个精选远胜 50 个堆砌
误区 3让 AI 生成配置文件
❌ 错误认知让 AI 来写 CLAUDE.md、Linter 规则、Hooks 配置
为什么错AI 不了解项目隐性约定和团队文化，生成的配置泛泛而谈
✅ 正确做法人类定义策略和约束，AI 只辅助语法实现。核心决策权在人
误区 4会话结束时才跑全量测试
❌ 错误认知让 Agent 写完所有代码，最后再跑一次完整测试
为什么错错误累积到后期才发现，修复成本极高，连锁错误难定位
✅ 正确做法增量测试——每完成一个关键步骤就验证一次
误区 5把所有知识塞进 CLAUDE.md
❌ 错误认知CLAUDE.md 越长越好，把项目文档、API 说明、最佳实践全塞进去
为什么错挤占有效信息空间，Agent 注意力分散，维护成本极高
✅ 正确做法CLAUDE.md 只放最关键的约束，详细信息通过 RAG 按需加载
六大开放问题
Harness Engineering 还在快速演进，以下问题目前没有标准答案：
Q1Harness 的通用性边界在哪？一个项目优化的 Harness 能否直接迁移到另一个项目？迁移成本有多高？
Q2多模型 Harness 如何统一？不同模型的行为差异很大，同一套 Harness 能否同时服务多个模型？
Q3Harness 本身的测试标准是什么？我们用 Harness 测试 Agent，但用什么测试 Harness？
Q4Agent 自主修改 Harness 的边界？能否让 Agent 自己优化 CLAUDE.md 或调整 Linter 规则？安全边界在哪？
Q5组织级 Harness 如何治理？大型团队中，不同项目组的 Harness 如何保持一致性又不失灵活性？
Q6Harness 与模型能力的均衡点？在什么情况下，应该优化 Harness 而不是升级模型？反过来呢？
开放问题没有标准答案，但思考它们本身就有价值。这些问题的答案很可能决定 Harness Engineering 未来 2-3 年的演进方向
本节小结
📌 本节核心要点
- 误区 1：不要预先设计完美 Harness，从最小可用开始
- 误区 2：不要堆砌 MCPs，3-5 个精选工具远胜 50 个
- 误区 3：配置文件的核心决策权在人，AI 只辅助语法
- 误区 4：增量测试，不要等最后才跑全量
- 误区 5：CLAUDE.md 要精不要多，关键约束 > 信息堆砌
- 开放问题：6 个方向值得持续关注和思考
思考题
- 五大误区中，你最容易犯哪个？你过去的项目中是否踩过这些坑？
- 关于"Agent 自主修改 Harness"这个开放问题，你认为应该允许 Agent 修改到什么程度？风险和收益如何平衡？
- 如果你要给新手一条关于 Harness 的建议，你会说什么？这条建议是否避开了上述误区？
下一节预告
误区和问题说完了，课程也快到尾声。最后一节，我们聊聊人的角色转变——在 Harness Engineering 时代，开发者要变成什么样？