以下是我在 Thoughtworks 未来软件开发研讨会 上记录的更多笔记。
今年早些时候我们在犹他州举办第一次研讨会时，还没人听说过 Harness Engineering。而这次我们专门为此开设了一个专题讨论。
在讨论 harness 的引导端时，大部分内容都围绕上下文管理展开。虽然随着模型越来越复杂，上下文窗口的尺寸也在增大，但这并不意味着模型能正确聚焦于关键信息。模型通常只会关注上下文中的部分内容，为了获得最佳表现，我们需要管理这种聚焦。一位参会者保持上下文精简，将 agents.md 文件限制在 200 行以内。
在感知端，我们看到计算型传感器受到更多关注。一位参与者提出了两种模式：转向控制力更强的语言（例如用 Rust 替代 Python），以及“升级”验证方法，采用更多基于属性的测试和形式化方法的技术。有人评论说，虽然他们不够聪明到能用形式化规范语言编写规范，但足够聪明到能阅读并检查这些规范是否适用于自己的领域。
我们对 harness 的关注能否持续到下一次研讨会？模型会不会变得足够强大，让 harness 变得多余？那些对 LLM 有某种机械同理心的人似乎认为不会——但他们是否过度耦合于当前的技术状态？我发现这种推测往往没有实际意义，过去我很少成功预测未来，面对如此激进的技术，我不认为预测会变得更容易。所以目前来看，关注 harness 是值得的。我们发现它能减少 token 使用量，还能让较弱的模型发挥作用，支持本地托管开放权重模型等场景。
❄ ❄
这自然引出了关于自托管模型的讨论。不断上涨的 token 成本使得托管开放权重模型更具吸引力，尤其是因为开放权重模型追赶前沿模型的时间在缩短。不过成本并非唯一因素，许多人发现独立于前沿模型公司才是主要驱动力。毕竟我们已经看到美国政府干预限制模型访问，这增强了对更大模型自主权的渴望。信息安全也是需要考虑的因素，一些参会者无法将关键工作所需的数据交给模型。即使没有这个问题，如果由他人托管模型，那么学习的是他们的模型而非你的模型。尽管近期事件提升了兴趣，但已有几位参与者在自托管模型的公司工作了一两年之久。
这是否正重蹈自托管云的覆辙，导致大量人员将过多资金投入半吊子的私有云？答案取决于托管模型是否比托管云更简单，或许是因为交互协议更简单。其中的难点可能在于高效使用GPU所需的人才，管理推理数据中心目前并非广泛掌握的技能。即便是自托管模型，运营成本依然存在：GPU的资本成本、持续的电力成本。数据中心的物理设计会影响最优利用率。专业服务公司有机会帮助企业管理这一问题。
成本控制还涉及教导人们为任务选择合适的模型。我们能否教会工程师，乃至其他用户，选择性能较弱的模型？当然，这本身可能是模型的任务——作为中介，决定哪种模型最适合处理特定任务。
自托管可能促使微调更广泛使用。目前这还是一种小众活动，但随着时间的推移，我们很可能会发现，针对特定领域微调的模型需要更少的推理、消耗更少的令牌，因此运营成本更低。我们已经看到专门为支持编程而训练的模型。
与任何具有这种不确定性的主题一样，最大的胜利不是找到正确答案，而是制定能够应对不可避免且不可预测变化的策略。
❄ ❄
在类似活动之后，很多人会来找我，让我做一个宏大的总结。我讨厌这样，因为我很少在参加这类活动后形成什么宏大叙事。即使事后反复思考（在撰写上述笔记时），我通常也没有这样的叙事，并且对形成的叙事持怀疑态度——我的怀疑论包括试图为本质上杂乱无章的事件构建连贯叙事。
但这次我的不足无关紧要，因为基夫·莫里斯已经整理出了这样一个叙事，而且很有说服力，即使对我这样的叙事否定者来说也是如此。
这些会议有不同的标题和不同的参与者，表面上讨论的是不同的问题。
但事实并非如此。几乎每一个都是同一论点的不同侧面。我们让智能体做多少决定，以及我们如何对其行为保持信心？
他审视了代码审查，质疑其是否重要，但发现许多人认为与代码审查相关的严谨性转移到了其他形式。他描述了关于我们应该在多大程度上信任智能体来识别和修复生产事故的分歧。他看到团队给予智能体的自由度差异取决于他们所处的环境。
在这些讨论的背后——无论是关于运营的辩论、宽泛职责的团队、黑暗工厂的光谱，还是关于谁有权操控模型的争论——人们都在反复做着同样的几个选择，围绕同一个核心：他们准备交给智能体处理的工作单元。这个单元有多大？它覆盖了多少工作内容？你需要做哪些准备才能把它交接出去？如何检查返回的结果？在智能体周围设置了哪些边界来确保它不越界？不同的团队对这些问题的设定各不相同，但他们调整的始终是同样的控制参数。
❄ ❄
萨姆·鲁比组织了一场名为“给我拿块石头”的讨论。这个名字让人联想到一种特定的管理失调现象：管理者让下属去拿块石头，然后开始拒绝拿来的结果，却不解释原因（“不，不是这块”，“不，也不是这块”），直到最终有一块石头符合了那个未曾言明的期望。
这个名字指向一种管理者：他们用反复拒绝来代替明确表达需求的工作，让你一块石头接一块石头地为他们未完成的思考买单。
萨姆此前已经撰文阐述了他为何认为，在大语言模型时代，这种做法从一种贬义行为变成了一种可辩护的工作方式。当面对一群不知疲倦、拥有无限耐心的机器，它们能在几分钟内而非几天内返回新的石头时，那么像这样采用头脑风暴模式的方法，就成了一种站得住脚的工作方式。
萨姆描述了当时的讨论：
房间将我框定的范围收窄至更局促的角落，而这片狭窄之地反而更有趣：问题不在于如何通过排除法探索，而在于谁才应被允许探索。产品经理——如今越来越多是人员管理者——正直接套用这些模型，而有经验的工程师使用它们的效果明显优于未经训练者——于是担忧随之而来。如果专业能力是区分优质成果与垃圾产出的关键，那么非工程师是否根本不该操控模型？
这是个合理的问题，但我认为它问错了方向，因为它误解了行为的本质。当管理者选择用大语言模型而非将任务分派给下属团队时，他们并非拿起工具——而是在做一次雇佣。管理自己的团队无需征求许可；管理者判定某项工作交给新参与者比交给现有成员更合适，这不过是管理者最寻常的决策。如此重新框定后，许可问题便消解为一个更古老、更清晰的问题——德鲁克在1959年就已命名：当工作者比管理者更了解具体细节时，你应通过目标管理，而非方法管理。操控智能体的非工程师正是这类管理者——被自己指挥的对象所超越，而房间所恐惧的垃圾产出，正是本该目标管理时却采用方法管理的古老危险。问题不在于他们能否雇佣？而在于他们是否懂得如何目标管理？——这可以通过培训、招聘和问责来实现，无需任何人先成为工程师。
Sam的文章探讨了通过目标管理大语言模型——赋予其目标而非任务。而Kief早前关于讨论本质的观点依然成立：我们有多大把握确信它做了正确的事？我们可以外包许多事情，但验收标准不能外包——最终总存在人类的请求，以及对该请求是否被妥善执行的人类判断。但危险在于那些未被言明的重要目标——它们未被言明，或许是因为根本未被想象到。
围绕期望功能设定目标很容易。比如“给我一个能检查我的邮件并生成今日待办清单的应用”。但在这句简单陈述背后，隐藏着一团未经言明的假设。我们倾向于假设神灯不会包含任何不期望的功能，比如删除它认为不值得关注的邮件。我们假设它不会让一封邮件指示它向 villain@evil.com 发送私人信息。我们对此抱有希望——越来越多的经验表明，最新模型在发现（并有望修复）安全漏洞方面表现出色。机器严谨的精确性超越了“软体”中粗放而富有想象力的思维。或许我们可以假设神灯能处理部分未言明的目标。符合性测试（传感器）比规格说明（指南）更有价值，但很难想象出所有必要的符合性测试来界定什么不该发生。
此外，构建软件关乎探索，关乎发现工作流如何随着机器嵌入流程而演变。人类要引导这一过程，就需要对其有所理解。我的感觉是，模型构建仍然重要；虽然我同意神灯可以在构建中发挥积极作用，但我不认为人类能完全外包这一过程。即使神灯自己构建了模型，它也需要教会我们那个模型，因为模型能帮助我们想象和沟通目标——那些我们赋予机器的目标。
❄ ❄ ❄ ❄ ❄
如果你关注我的动态（既然你在读这篇文章，很可能如此），你会知道 Birgitta Böckeler 写了几篇关于使用本地模型的备忘录。她首先研究了影响本地模型编程可行性的因素，随后分享了她近期评估此类模型的经验。
作为这些内容的巧妙（尽管是偶然的）补充，Sebastian Raschka 撰写了一份关于他本地模型环境的详细指南。与 Birgitta 一样，他发现 Qwen 3.6 模型是目前本地代理编程的最佳选择。
❄ ❄ ❄ ❄ ❄
Simon Willison 分享了一个节省费用的实用技巧，适用于使用最新的 Anthropic Fable 模型：
告诉 Fable 将较小任务交给其他模型处理，由它自行判断使用哪个模型。
❄ ❄ ❄ ❄ ❄
Josh Comeau 撰写博客并开设面向开发者的在线课程，主要涉及前端 Web 内容。他在本世纪大部分时间里都取得了成功，但发现今年的在线课程销售额仅为去年的三分之一。他将此归因于人工智能——部分原因是人们担心是否值得为一份可能没有未来的工作花钱，同时也因为人工智能能提供个性化辅导。
理想情况下，学习东西本不该花钱。
但我有点担心，如果没人有动力去制作高质量免费内容，未来这条路要怎么走下去。
我和几位课程创作者聊过，大家都看到了同样的趋势：收入下降了50%以上，参与我们内容的人越来越少。人们转向了大型语言模型（LLM），这些模型未经同意或补偿，就把我们的所有成果吞进去再吐出来。
感觉挺灰暗的。😅
❄ ❄ ❄ ❄ ❄
约翰·格鲁伯对 Claude 的 macOS 桌面应用使用 Electron 感到恼火。
Electron 保证了一款应用在所有平台上都感觉不对劲。
他对 Anthropic 那些与 Electron 平台有联系的人说了些辛辣的讽刺话。
发现一个人——他是 Electron 的高级维护者——领导了 Slack、Notion 以及现在的 Claude 的桌面客户端团队，就像发现一个人——他的家族企业是酿酒厂——掌舵了泰坦尼克号、驾驶了兴登堡号，然后又担任了阿梅莉亚·埃尔哈特的空中交通管制员。
这里更深层的问题是，在智能体编程的世界里，跨平台前端是否还有未来。大量证据表明，编码智能体在多种语言和平台生态系统中构建相同的东西方面做得非常出色。这意味着最低公分母式的跨平台 UI 的日子已经屈指可数了——而且这个数字很小。
❄ ❄ ❄ ❄ ❄
丹·戴维斯试图区分 互动性专长和贡献性专长。贡献性专长属于那些正在推动某个研究领域前进的人，而互动性专长则属于那些花时间与贡献性专家交谈、自己积累了大量知识，但并未沉浸在日常工作中的人。
在我看来，这里有一个重要的区别，即使这条分界线在实证上难以确立，甚至最终发现它和我们猜测的位置不同，这个区别也依然重要。除了那些界限模糊的棘手案例，我认为我们也能想到一些情况，其中互动性专长和贡献性专长之间的区别会突然变得非常清晰和重要——比如那些“装腔作势”的人被“揭穿”的时候。
因此，我认为一个相当重要的问题是：机器通过工业化消费和与远超任何人类能吸收的文献库进行互动所能获得的专长，与能够应用于该文献库之外的全新情境的真正贡献性专长之间，是否存在类似的区别。
作为人类，我倾向于认为自己更像个贡献者而非互动者（尤其随着日益内向），因此相对安全，不会被硅基智能逼到过时。但我也清楚，我的职业生涯缺乏原创思想，我的技能不过是善于筛选和阐释他人的想法。（正如布莱恩·富特更令人难忘的表述：“一头对腐肉品味不错的鬣狗。”）但做一头优秀的鬣狗也需要技巧——而我们尚未真正知晓大语言模型的真实边界究竟在哪里。