你的软件工厂有多开放？Tessl 谈 AI 软件工厂的知识可迁移性

你的工厂变得更智能了。你能把这份智能带走吗？

在把你的公司工作托付给一个软件工厂之前，先问两个问题：你能把你的上下文带进去吗，你能把它学到的东西带出来吗？第一个问题得到了大量关注。连接你的代码仓库。添加你的文档。配置你的工具。告诉智能体你的团队如何工作。

随着每一次运行，第二个问题变得愈发重要。你的工程师解释架构决策。审查者纠正反复出现的错误。事故揭示出从未被写下的约束。评估确立了什么样的工作是可接受的。随着时间推移，工厂积累起对你业务越来越有价值的理解。

如果你更换模型、编码智能体、运行框架或工厂本身，这份理解有多少能随你一起走？一个接受你的知识却困住你所学之物的工厂，是一扇单向门。

有价值的产出不止是代码

历史上的工厂类比有助于说明其中的利害关系。购买一件制成品并不会自动赋予你生产它所需的知识。你获得的是产出，而制造商保留着流程知识：如何处理异常、检测缺陷、改进下一次生产。这往往是一笔明智的交易。大多数公司应该购买商品化组件。但当生产流程中包含区分你业务的知识时，决定这些知识在哪里积累就成为一个战略选择。

在一个由 AI 驱动的软件工厂中，你的员工帮助创造这些知识。他们提供上下文，展示判断力，并解释为什么一个看似合理的答案是错的。你的运营揭示生成的软件是否真正有效。工厂生产代码。它也生产出关于你的公司如何构建软件的更好理解。

你可以拥有每一行生成的代码，却仍然依赖某一个平台来获得产生这些代码的理解。失去这份理解意味着要花钱去重建决策、重新发现异常，并再次解释同样的教训。代码可以离开，而专有技术却留了下来。

开放组件只是一个起点

有几种有用的方式可以让工厂变得开放。支持多种模型。连接外部编码智能体。在客户控制的环境中运行。为现有工具暴露接口。每一种都创造了宝贵的自由。但单凭任何一种，都无法告诉你通过生产积累的知识能否迁移到别处。

下一个问题涉及在该基础设施内部积累的知识：你能独立地检查、提取并重新利用什么？将信息保留在你的环境中解决了一种顾虑。在模型之间做选择解决了另一种顾虑。将你维护的技能、架构决策、评估用例和学到的约束带入一个不同的生产系统，则解决了又一种依赖。

一个开放软件工厂应该让这成为可能。它的上下文和学习成果应该在你的掌控下保持可理解、可治理、可复用，并拥有超越任何单一组件或供应商的生命力。

把你的上下文带进来

你的组织已经拥有值得利用的知识。它存在于代码仓库、内部文档、工单、架构决策、业务系统以及人们的经验中。引入上下文意味着将这种理解与工作连接起来，而不需要公司在一个新产品中重新创建自己。

连接器可以检索文档。有用的上下文还能告诉智能体该文档是否是最新的、哪个协议优先、以及在哪里适用例外。来源、权限和关系与文本同样重要。

工厂应当容纳你现有的技能和指令、你的模型网关、你的评估、你的可观测性以及你的审批工作流。在这些系统已经运作的地方，它们就是你带来的生产能力的一部分。你还应该能够带入自己的循环。从提供的工作流开始，增强它，或者用反映你需求的加固序列替换它。公司需要控制上下文如何被收集、操作如何被检查以及反馈如何被纳入。

将你的学习向前推进

考虑一个编码智能体绕过内部服务直接写入数据库。该实现看起来合理，但忽略了该服务提供的授权和审计行为。审查者发现了它并解释了该服务存在的原因。

直接的修复是一个更好的拉取请求。持久的改进可能是多个产物：

• 一个解释边界及其理由的架构决策。
• 一个描述如何进行此类变更的技能。
• 一个检查智能体是否尊重该边界的评估用例。
• 一个在审查前捕获违规的自动化检查。

这些产物将一次纠正转化为可以指导未来工作的知识。当另一位开发者、智能体或工作流接手时，它们应当保持可访问。导出的对话记录是对话的证据。它不一定告诉你哪条经验被采纳、适用于何处，或者如何验证另一个系统正确使用了它。

有用的提取保留含义。一条经验需要其来源、范围、审查状态和支持证据。一项技能需要其依赖项。一个评估需要足够的环境以便再次运行。这也是为什么学习需要判断力。变通方法不应悄然成为政策。临时例外不应成为普遍规则。必须有人决定什么值得保留，并测试所提出的改进是否有帮助。

一个实用的起点是将开发工作中反复出现的问题转化为对技能和工作流的改进。这些改进应当成为你可以在整个工程系统中使用的资产。

让开放性可观察

“你的工厂有多开放？”应当可以通过团队能够展示的东西来回答。

透明度：你能检查指导一次运行的上下文、它使用的来源以及反馈后所做的更改吗？工程师能否理解并质疑支配生产的规则？这涉及可观察的输入、产物和操作；它不需要访问模型推理的每一个内部步骤。

可复现性：你能重建某个结果背后的相关指令、版本、工具响应和条件吗？概率系统可能产生不同的结果，但保留的上下文和本地测试环境使重放和比较变得有意义。

互操作性：你的知识能否在模型、编码代理和运行框架之间保持可用？模型独立性只是其中一层。应用、执行循环、记忆系统和工具各自都可能引入依赖。适配器和重新测试可能是必要的；但重建你的组织理解不应成为切换的代价。

生态复用：你能否用一个工具编写技能，用另一个工具评估它，并在多个工作流中使用它？你能否保留现有的网关、连接器和监控？开放的工厂让你能够组合各种能力，而不是在每个平台内反复重建它们。

技能、插件、代理指令文件和新兴协议在这里都有帮助。仅靠共享格式无法保证等价的行为、权限或记忆语义。证据在于另一个系统能否使用这些产物并通过你的检查。当你能把导出物重新投入使用，它就成了一条退出路径。

上下文成为团队可以共同改进的东西

让知识显式化、可复用还有另一个结果：它能让组织对自身更加透明。以前在私下对话中解释的服务约定，变成了产品团队可以找到的指导。反复出现的评审意见变成了人们可以讨论的规则。一次事故的教训可以同时改进一项实现技能和一个自动化审查器。

上下文成为具有协作生命周期的持久产物。人们可以提出变更、审查证据、解决分歧，并看到哪个版本是权威的。其他团队可以在此基础上继续构建。这种协作很重要，因为供应商锁定只是知识被困住的一种方式。部门、代码仓库和单个代理的记忆也可能成为孤岛。一家公司可以控制自己的基础设施，同时维护着关于其业务运作方式的多个互不兼容的版本。

共享上下文并不要求普遍访问权限。敏感信息仍然需要适当的权限。目标是让知识对有权使用它的人和工具可用，无论他们的工作在哪里进行。

从一个工作流开始——并演练这次迁移

开放的软件工厂不需要先构建整个平台才能获得价值。选择一个有边界的工作流，团队在其中反复解释相同的上下文或纠正相同的错误。连接其权威来源。捕捉一些有用的经验教训。把它们转化为持续维护的技能和评估用例，并指定专人负责其质量。

然后尝试在其他地方使用这些产物。把工作流交给另一个编码代理。通过不同的运行框架运行其评估。让另一个团队应用这项技能。注意哪些东西保留了下来，哪些需要适配，哪些在不知不觉中依赖于原始环境。这项练习让开放性变得具体。它还能改进文档，并在你需要更换供应商之前很久就暴露出各种假设。

本地、本地部署、VPC 和托管部署都可以发挥作用。根据工作负载及其需求来选择它们。仅凭部署位置无法告诉你积累的知识是否可检查或可复用。

所有权也涉及维护。上下文会过时，评估需要关注，集成需要投入精力。对于通用型工作，完整的管理式产品可能是正确答案。把你的投资集中在能够让你的业务与众不同、且重建成本高昂的知识上。

保持开放

一个随使用而改进的工厂是有价值的。这种价值应当增强你组织的能力，同时保留其选择余地。购买优秀的组件。采用标准技能。在有用之处使用托管服务。掌控上下文、工作流、评估和学习，让生产系统真正属于你。

对开放软件工厂的检验标准是：你能否将自己的理解带入其中，看到这种理解如何变化，并将由此产生的知识带向前方。你的工厂带给你的知识和选择，应当比你带入时更多。