我花了一个周末阅读关于Harness Engineering的最佳博客。最常出现的实践是:

我花了一个周末阅读关于Harness Engineering的最佳博客。最常出现的实践是:

转发——内容作者:Jérémy Surget

我花了一个周末阅读关于Harness Engineering的最佳博客。最常出现的实践有:

我们现在知道,今天的harness与其背后的模型同样重要

以下是最突出的技术:

1. 记忆存在于上下文之外

仓库、文件系统和git充当记忆。每个会话从上一个会话结束的地方继续,上下文永远不是真相的来源

2. 谨慎对待上下文限制

上下文过满会导致幻觉和性能下降。为限制这一点,你需要按需加载工具和技能,并将大量输出卸载到磁盘上的文件中。更不用说为缓存保持稳定的提示前缀

3. 规则由代码强制执行

而非由提示执行。Linter、测试、钩子和沙箱使约束可验证。Agent必须能够自我验证(测试、日志、截图),然后才能说任务完成

4. 持久性和可观测性

对每一步设置检查点,使操作幂等,并使一切可追踪。Agent会失败,会话有时会断开或停止。你需要能够确保一切都能从停止的地方精确恢复

5. Harness必须保持可塑性

根据生产反馈,你的harness将不得不改变以适应。保持其最小化和可塑性将让你快速适应

LinkedIn来源

文章我花了一个周末阅读关于Harness Engineering的最佳博客。最常出现的实践有:首次发表于les plumes qui mordent。



常见问题
Harness Engineering常见问题

初学者问题

什么是Harness Engineering
它是设计系统的实践,使harness——围绕你的代码的工具、流水线、护栏和反馈循环——让良好的工程成为容易的路径,让糟糕的工程变得困难

为什么它重要
因为大多数质量问题来自摩擦而非粗心。一个好的harness能及早发现错误,自动化无聊的工作,让团队更快交付,减少意外

Harness的核心部分是什么
通常包括CICD流水线、自动化测试、静态分析和linter、预提交钩子、可观测性和清晰的部署护栏

我需要一个大团队才能开始吗
不需要。从基础开始——一个CI流水线、自动化测试和一个linter。你可以随着代码库和团队的成长来扩展harness

Harness和常规DevOps工具之间的区别是什么
DevOps工具是基础设施,harness工程是对该工具如何日常指导和约束工程师的刻意设计。它关乎开发者体验,而不仅仅是工具

中级问题

实践中最常见的收益是什么
更快的反馈循环、更少的生产事故、更一致的代码质量、更容易的上手,以及更少花在手动检查和救火上的时间

团队遇到的最常见问题是什么
流水线缓慢、测试不稳定、linter和警报噪音过多,以及护栏过于严格以至于阻止合法工作。通常的解决办法是针对速度和信号进行调优,而不是增加更多检查

我如何处理不稳定的测试
将不稳定视为bug。隔离它们,快速修复或删除它们,并随时间跟踪不稳定率。Harness中不稳定的测试会训练人们忽视harness

什么是好的第一个改进
加速反馈。让CI在十分钟内完成,并为格式化和linting添加预提交钩子。快速反馈比任何政策文件都更能改变行为

我如何获得团队的支持
展示节省的时间和避免的事故。当harness让工程师的日常工作更轻松时,他们会采纳harness改进,而不是当它增加步骤时

高级问题

我如何设计不会拖慢人们的护栏
让安全路径成为默认路径,让快速路径