上周，我在机械果园主办的果园静修日度过了一天。活动汇聚了多位软件开发从业者，共同探讨在智能体编程兴起背景下该行业的未来。会议遵循查塔姆宫规则，因此我无法注明听到的评论和故事来源。（若有人认出自己的观点并希望署名，请告知。）以下是我笔记中摘录的几个要点。
❄ ❄
一个团队用Rust语言开发了GNU COBOL编译器的行为克隆版本。最终成果是7万行Rust代码，仅用三天完成。这再次印证了大语言模型将现有代码移植到新平台的能力。完善的回归测试在此过程中价值极高（我不清楚GNU COBOL的测试质量如何）。若能访问现有实现，构建测试套件也是可行的。
❄ ❄
大型规格文档对人类审阅者而言可能过于复杂。一位与会者分享了让大语言模型采访人类专家的想法——通过向人类提问来验证规格的正确性，这属于质询式大语言模型的一种形式。
❄ ❄
虽非AI专属话题——但我欣赏一位与会者的观点：他们为组织提供咨询时，首要任务是阅读其变更控制委员会的指南。这些指南是过往失误留下的“伤疤组织”。我常言：要理解事物为何如此，需了解其演变历史。这似乎是挖掘历史关键脉络的绝佳方式。
❄ ❄
我那些从事遗留系统现代化的同事，长期以来对“迁移加转移”（将遗留系统移植到新平台同时保持功能对等性）颇为不屑。
我们认为这种模式错失了巨大机遇。旧系统往往随时间膨胀，许多功能用户从未使用（据2014年Standish Group报告达50%），业务流程也历经演变。替换这些功能纯属浪费。相反，应努力退后一步，理解用户当前需求，并根据业务成果和指标确定优先级。
但这一观点形成于大语言模型移植代码能力出现之前。一位深耕该领域的与会者表示，他们认为如今应将“迁移加转移”至新平台作为遗留系统迁移的首要步骤。成本已不再像过去那样高昂，更好的环境能让后续演进大幅降低成本。只是别止步于此。
几位与会者来自金融行业，因此他们深陷于复杂的遗留环境、监管控制以及软件在资金处理上出错可能带来的重大风险等问题之中。他们面临的一个难题是，当一款金融产品在多个司法管辖区推出时，每个辖区都有各自需要满足的法规，这会导致软件复杂性剧增。在判断适用哪个司法管辖区，以及在流程的哪个节点选择正确的规则集方面，存在大量软件复杂性。
这里的问题是，代理式编程的快速性是否意味着我们可以为每个司法管辖区构建独立、更简单的系统。然后，我们利用大语言模型来确保它们之间的一致性，这样当产品规则发生变化时，每个系统都能在其自身环境中反映这些变化。
软件设计的很大一部分工作在于识别不同业务场景中哪些是相同的，哪些是不同的。在那些相同且需要保持一致的地方，我们理所当然地会警惕代码重复，因为这会增加更新成本和不一致的风险。有趣的问题是，大语言模型能发挥什么作用，为我们提供解决这一难题的新工具。
❄ ❄
与这类聚会常见的情况一样，大家也关心初级开发人员的问题。当我们与“精灵”合作时，我们的价值来自于良好的判断力——我们该如何传授这种能力？这个小组确实有一个共同工具——结对编程。结对编程的一个关键好处始终是技能转移，在这里，经验丰富的代理式程序员可以传授他们在软件设计以及如何利用“精灵”达成目标方面的判断力。而初级开发人员也常常能分享一两个技巧——那双新鲜的眼睛在我们迈向代理式未来的转变中尤其宝贵。
❄ ❄
从历史上看，我们使用计算机系统来为混乱的人类流程带来秩序。人工智能是否正在逆转这一趋势？
❄ ❄
如此多的软件都涉及数据转换。那边的那些记录需要被这边的这些 API 消费，但数据的结构存在差异，这通常是因为它们位于不同的限界上下文中，因此我们必须进行一些转换。代理特别擅长编写这类转换代码，这类代码往往比我们期望的更加繁琐。
❄ ❄
混沌工程已成为一种提高弹性的宝贵技术，因 Netflix 的 Chaos Monkey 而闻名，它会随机破坏线上服务，以观察生态系统如何反应和恢复。那么，针对人工智能的 Chaos Monkey 会是什么样子？它是否会故意在流水线中引入幻觉，以检查传感器是否能够捕捉到它们？
❄ ❄ ❄ ❄ ❄
回到我的办公桌前
关于结构化提示驱动开发（SPDD）的文章，作者在问答部分回答了许多问题。其中有一个问题特别引起了我的注意：
你有没有考虑过让一个智能体来执行提示/规范审查本身——不是让人来审查 Canvas，而是让一个智能体读取 REASONS Canvas 以及代码差异，并验证它们是否对齐？
回复中提到，有一个可用的命令可以做到这一点，但存在一些缺点。特别是，不自动执行此操作的一个原因是：
让人学习。审查也是人类从 AI 的选择中学习的地方——模式、权衡、他们未曾想到的选项。将人类排除在外会加快速度，但会阻碍 SPDD 旨在保护的长期技能成长。[…] 一旦积累足够多的决策规则，让我们真正有信心，我们可能会逐步将更多审查工作交给智能体——但人类从 AI 中学习的那部分，我们计划保留下来。
我们判断一个 AI 工具价值的方式之一，是看它能在多大程度上帮助我们人类更好地了解我们所居住和建造的世界。
❄ ❄ ❄ ❄ ❄
上周，我莫名其妙地伤到了手肘。完全不知道是怎么发生的，没有任何一个瞬间让我喊出“哦糟了”。它只是逐渐开始疼痛和肿胀。我一生中避免运动损伤的策略1这次背叛了我。我用了冰敷和布洛芬，肿胀消退了，但活动范围却变得更差了。我很庆幸自己在英国童年时期学会了用刀叉，所以通常用左手吃饭。
我注意到，活动范围的丧失是在我回家后开始的，那时我又开始整天坐在电脑前。我可能不会直接用到手肘，但我的右手要大量打字和操作鼠标。我的办公桌设置相当符合人体工学，有好键盘、鼠标腕托和椅子上的扶手。但即便如此，我回家后使用电脑是否让手肘恶化了？我无法想象不用电脑，对我来说，写作已经成为一种无法停止的习惯。但也许我应该借此机会探索语音输入——毕竟大多数人说话比打字快。
很多年前我试过这个，当时一位同事告诉我，语音识别一旦适应了你，效果会非常好。我试了，确实，即使在那些 AI 尚未普及的日子里，语音识别也非常出色。但它不适合我。当我写作时，我会快速在 Emacs 中输入单词，但几乎立刻就会回去编辑它们。写两个句子，编辑它们，再写一个，重新编辑整个段落。看到文字和思考文字之间的来回切换非常紧密——我无法仅仅口述我的文字。
这让我进一步反思。我直到二十多岁才开始用电脑写作。中学时我手写，大学时用打字机。但那些媒介不支持我现在这种不断重写的习惯。如果文本编辑器没有被发明出来，我还会成为作家吗？
❄ ❄ ❄ ❄ ❄
詹姆斯·普里查德认为，许多开发者在产品中过度使用运行时代理，而LLM更适合作为函数使用。
代理的问题不在于它们不起作用。而在于它们的工作方式不可预测。你用已知的执行路径换来了“自主性”，而这通常意味着“我不知道它会做什么”。当基于代理的功能在生产环境中出问题时，你调试的是一份对话记录，而不是堆栈跟踪。
大多数“代理”用例实际上是工作流，是一系列已知步骤，其中一两个步骤恰好涉及LLM。你不需要自主性来完成这些。你需要的是函数调用。
他指出，函数可以预测地组合，所以如果你知道工作流，那么在程序文本中组合比让代理自己协调更好。这样更快，需要的token更少。处理失败也通常更容易，因为交互的范围更小。
❄ ❄ ❄ ❄ ❄
普里查德还认为，人们使用技能文件的频率远超合理范围。他认为人们积累了成堆的Markdown技能文件，但LLM使用它们时并不一致，常常在需要时遗漏，或者在不必要时膨胀上下文。许多本应放入技能文件的内容，应该成为工具链的其他部分，最好是计算性的。技能文件只应在刻意、不频繁的工作流中使用。
对技能文件的痴迷是一种更深层模式的症状：人们在应该寻求架构时，却去寻求配置。
“LLM写不好测试。”不要写一个测试技能。你现有的测试不一致吗？测试设置复杂吗？修复这些问题，它就能写出好的测试，而无需告诉它怎么做。把它指向一个你引以为傲的测试文件。代码比英语更清晰。
[…]
最好的设置是你几乎不需要配置LLM。一个干净的代码库，清晰的模式，一个简短的项目配置来处理不明显的内容，自动化的钩子，也许还有一两个技能文件用于你特意运行的特定工作流。仅此而已。
❄ ❄ ❄ ❄ ❄
关于代理编程兴起的一个常被提及的观点是，我们必须开始在工作中处理非确定性。当然，这有些简化，因为软件开发的某些方面早已需要面对非确定性。一个显著的例子是分布式系统，而帮助我们探索分布式系统真正棘手领域的一位著名人物是凯尔·金斯伯里（Aphyr）。
上个月，他发表了一篇长文（PDF版有32页），阐述了他对由大语言模型驱动的未来的看法。标题《万物皆谎言，我猜》暴露了他对这一未来的缺乏热情。
有些读者无疑会感到不满，因为我没有花更多篇幅来赞美机器学习的奇迹——LLM在代码生成方面多么出色，Suno将哼唱的旋律转化为精美歌曲多么不可思议。但这篇文章并非关于开车有多快或多方便。我们都知道汽车很快。我想问的是，城市的形态会发生什么变化。
这篇文章值得一读，尽管它并不那么令人愉快。金斯伯里从一位显然对AI能力了如指掌的人的角度，提出了许多关于AI发展的担忧。
他认为，对这一切的最佳回应是我们应该停下来。他希望在写作、软件或个人生活中避免使用AI。他认为那些为AI公司工作的人应该辞职。然而，他也知道这些工具有用，并且想使用它们。
对于我们的AI未来，我既抱有希望，也感到悲观。从根本上说，我把任何强大的技术都看作一辆大巴士：我们要么上车，要么被它碾过。我选择上车，因为我认为设置一些障碍并不能阻止我被它的车轮压碎。也许如果我上了车，我可以加入一些人，稍微影响一下司机。我也非常不愿对任何事物的未来结果进行推测，更不用说像这样强大的东西了。18世纪末的早期工业家们是否知道他们引发的工业革命会带来什么？虽然它造成了许多伤害，但也使数百万人的生活水平大幅提高，至少那些国家上了这辆巴士的人是这样。AI可能会带来我无法想象的好处，尽管当它帮助一位朋友抵御帕金森病时，我能瞥见一丝希望。
这些希望是存在的，但金斯伯里的文章照亮了当下更黑暗的部分，提出了关于责任的严肃问题。
作为Mastodon实例管理员，我的部分工作是回应用户举报，有时这些举报涉及儿童性虐待材料，而我有法律义务审查并将这些内容提交给国家失踪与受虐儿童中心。我不想看到这些图像，真的希望自己能忘记它们。在那些阴暗的早晨，当我坐到电脑前，发现一条关于AI生成的性侵图像的审核报告时，我有时希望OpenAI等公司的工程师也能看到这些图像。也许这会让他们反思自己正在推向世界的技术，以及“对齐”在实践中究竟如何运作。
- 不要进行体育运动 ↩