楼上说得都很有道理！不过我感觉避免Agent放大技术债，有点像在跟AI玩猫鼠游戏。你以为搞定了，结果它总能找到新的姿势来制造麻烦。
我建议大家可以试试更“玄学”一点的方法，比如：
* 定期给Agent“洗脑”：用最新的代码规范和最佳实践“喂”Agent，让它保持“纯洁”。
* 让Agent之间互相Code Review：搞一个“Agent互助小组”，互相审查代码，看看能不能擦出不一样的火花。
* 引入“代码风水学”：认真研究一下代码的命名、结构，看看是不是符合“风水”，避免出现“煞气”，影响Agent的发挥。
当然，这些方法可能听起来有点扯，但说不定真的有用呢？毕竟，跟AI打交道，有时候就是要有点想象力！
我觉得短期内 Context Engineering 更重要，因为目前大模型的能力还有局限性，我们需要更多地依赖Context来提升模型的表现。但长期来看，Harness Engineering会更加重要，因为随着模型能力的提升，我们需要更多地关注如何构建一个可控、可靠的AI系统，确保AI的行为符合我们的预期。而且，当AI开始自主进化时，Harness Engineering的重要性会更加凸显。Context Engineering可以理解为“授人以鱼”，Harness Engineering则是“授人以渔”，哪个更重要，似乎不用多说了。
这说明了开发流程中，code review会变得格外重要，需要尽早发现不好的代码模式，阻止AI去学习，要建立一个定期的代码清理SOP，防止AI Agent胡乱使用。当然，前提是review的人自己不能是技术债的制造者。
持续集成/持续部署（CI/CD）流程也需要升级，需要更频繁地进行自动化测试和代码质量检查，以及早发现和修复潜在的问题。
这让我想起了“沉默成本”的概念。Agent不需要知道成功了多少次，只需要关注失败的case。让我想起了《原则》那本书里提到的，关注自身的错误，快速迭代才是正道。
在精益创业中，MVP（最小可行产品）也是类似思路，快速试错，尽早暴露问题，避免资源浪费，迅速找到PMF。
其实Harness Engineering的思想并不遥远，即使我们不是专业的Agent Builder，也可以用到日常的AI产品使用中。关键是养成习惯，多思考如何优化交互方式，让AI更好地理解我们的意图。举个例子，在使用AI绘画工具时，不要简单地输入几个关键词就完事。可以尝试更详细地描述画面细节、风格、光线等，甚至可以提供一些参考图片。这就是在设计一个更好的“Harness”，帮助AI更好地“驾驭”我们的想法。
这个思路太棒了！我想到一个更贴近生活的例子。现在很多智能家居设备都支持语音控制，但难免会遇到熊孩子乱说话的情况。如果直接把熊孩子的声音喂给控制Agent，可能会造成一些不可预测的后果，比如突然把音响开到最大声。借鉴“上下文防火墙”的思路，我们可以增加一个“指令理解Agent”，负责对语音指令进行语义分析，判断是否是合法的指令，然后再交给控制Agent执行。这样，即使熊孩子乱说话，也不会误操作设备。
谢邀。技术债这个事情，在AI加持下确实可能恶化。文中提到的Agent会将坏模式系统性复制，这很可怕。我补充一点，可以尝试引入“演化算法”的思想。Agent可以生成多个版本的代码，然后通过某种评价机制（比如测试用例的通过率、代码的复杂度等）来筛选出较好的版本，并让Agent从这些较好的版本中“进化”出新的代码。这样，即使Agent一开始学到了一些坏模式，也能在不断的演化过程中逐渐去除这些坏模式，最终生成高质量的代码。
“上下文防火墙”这个概念确实很有启发！不仅在代码生成，我觉得在很多需要LLM参与的复杂系统中都有用武之地。例如，在客服机器人场景下，用户的恶意输入可能会扰乱对话，导致机器人给出不恰当的回复。我们可以借鉴“上下文防火墙”的思路，设置一个“输入过滤 Agent”，专门负责对用户的输入进行清洗和校验，过滤掉恶意信息，然后再将干净的输入传递给核心的对话 Agent。这样，即使有恶意输入，也不会影响到核心 Agent 的正常工作。
各位说的都很有道理！我从安全角度补充一点，不仅仅是恶意输入，一些看似正常的输入也可能包含敏感信息，比如用户的身份证号、银行卡号等。为了保护用户隐私，我们可以使用“脱敏Agent”，在将用户输入传递给Agent之前，先对敏感信息进行脱敏处理，比如用*号替换掉部分数字。这样，即使Agent被攻击或者数据泄露，用户的敏感信息也不会暴露。
从管理学的角度来看，Harness Engineering的本质是风险管理和流程优化。对于非程序员来说，可以将其理解为：
1. 目标拆解：将复杂的目标拆解为可执行的子任务，让Agent逐步完成。
2. 权限控制：根据Agent的能力和风险级别，赋予不同的权限。
3. 监控与审计：建立完善的监控和审计机制，及时发现Agent的异常行为。
我觉得Harness Engineering对于非程序员来说，最重要的是要学会和Agent“对话”。
* 用清晰、简洁的语言描述你的需求，让Agent明白你的意图。
* 多给Agent一些例子，让它更好地理解你的需求。
* 耐心和Agent沟通，及时纠正它的错误。
记住，Agent也是需要“调教”的！
楼上说的都太学院派了，我来个更接地气的。避免Agent引入技术债，简单来说就是：
* 别让Agent直接操作生产环境！先在测试环境里跑起来，有问题及时回滚。
* 代码review是王道！无论Agent写得多好，都得让人review一遍。
* 把Agent当成实习生，多教它，多纠正它，让它慢慢学习最佳实践。
记住，Agent只是工具，人才是Owner！
我觉得建立一套完善的测试体系也很重要。不仅要进行单元测试和集成测试，还要进行“用户体验测试”和“安全测试”，确保 Agent 生成的代码不仅功能正确，而且用户体验良好，没有安全漏洞。如果发现问题，及时修复并更新测试用例，形成一个闭环。这样可以尽早发现技术债，避免其蔓延。
这个问题问到了点子上！除了定期清理，更重要的是从源头上预防。可以引入“代码风格指南”和“自动化代码审查”，强制 Agent 遵循统一的代码规范，及时发现和纠正不规范的代码。另外，可以建立一个“最佳实践知识库”，让 Agent 在生成代码时参考这些最佳实践，避免重复犯错。就像人类程序员一样，需要有规范和约束才能写出高质量的代码。
我想到了“用户体验设计”里的“防错设计”。比如，网站注册时，如果用户名已经被占用，系统会立刻提示，而不是等你填完所有信息才告诉你注册失败。这就是一种“只有失败才发出声音”的理念，避免用户浪费时间做无用功。当然，如果把所有错误的可能性都堵死，用户体验也会很差，所以需要找到一个平衡点。
对小团队来说，与其追求构建一个面面俱到的“Harness”，不如聚焦在解决特定领域的核心问题上。比如，专注于某个垂直行业的知识库构建，或者开发一个高效的 Agent 协作流程。这样可以形成自己的独特优势，避免和大公司正面竞争。小而美，才是生存之道。