软件不再把最终形态全部预设好，而是向用户交付一套可以继续组合和生长的能力材料。
从一句散热需求开始
假设一名工程师上传模型文件、规格书和几张现场图片，然后对系统说：
帮我检查这个方案能不能满足最高温度要求。如果基线不通过，给出几个可以继续仿真的改进方向。
在传统散热软件里，这句话还不是一个可以直接执行的任务。
工程师需要先创建项目，选择模型，填写工况、功耗、环境温度和目标温度，再启动求解器。基线失败后，他要自己阅读结果、判断问题、修改模型、重新求解，最后整理报告。软件提供了很多专业功能，但如何把这些功能串成一次完整交付，仍然依赖工程师自己。
如果换成一个普通 AI 聊天框，问题也没有真正解决。模型可以给出一些散热建议，却不知道当前模型是否有效、企业允许修改哪些参数、哪一步需要专家批准，也无法保证它真的调用了求解器，更无法留下可以审计的工程记录。
我们最近在 Silieco 中做了一条散热仿真 SOP。它没有试图让一个 Agent 冒充散热专家，而是把一次散热工作拆成八个可以被管理的阶段：
散热需求提取
→ 需求与验收确认
→ 模型预检
→ 基线仿真
→ 结果判定与候选方案
→ 候选方案确认
→ 候选方案复算
→ 报告交付
Agent 先从用户说明和附件中提取工况、温度目标、关键器件和约束，把确定事实、工程假设与缺失信息分开。目标温度、运行工况、关键器件或模型文件没有确认，流程就不能继续。
基线完成后，确定性规则负责区分两件事：求解任务是否执行成功，以及散热结果是否通过。结果不达标时，Agent 可以结合当前指标和已有方法生成受限的候选方向，但不能直接修改模型。工程师需要明确选择一个方案，或者全部驳回。只有留下结构化批准记录，系统才允许进入下一轮复算。
最终交付的不只是一段对话，而是一组可以追溯的产物：需求快照、验收标准、模型校验、基线结果、候选方案、人工决定、复算结果和最终报告。
散热求解器在这里不是 Silieco 内部的一项固定功能，而是一个可以被连接和替换的外部专业服务。Silieco 通过稳定的任务契约调用它，持续接收 accepted → running → succeeded 等状态，再把基线结果、候选批准、复算和报告带回同一次工作流。
这也暴露了一个比“内置哪一个求解器”更重要的问题：
当需求、Agent、Skill、SOP、外部服务、人工决策和交付产物可以被自由组合时，我们交付的还是一套传统软件吗？
软件本来应该很柔软，最后却被做成了水泥
软件在理论上是一种非常柔软的材料。同一台计算机可以成为写作工具、设计工具、数据库客户端或仿真平台，区别只是它运行了什么程序。
但普通用户实际得到的软件往往是凝固的。
开发者提前决定页面、菜单、按钮和业务流程，用户购买以后学习如何操作。只要需求落在产品预设范围内，这种方式稳定、清晰、容易支持；一旦用户的真实工作和产品假设不一致，他通常只有三个选择：等待厂商排期、购买定制开发，或者在软件外面继续用表格、脚本和人工流程补洞。
用户本来想完成工作，最后却不得不调整自己的工作方式去适应软件。
这不是一个新问题。Alan Kay 很早就用黏土比喻软件，希望普通人能够轻松描述自己需要的工具。后来，End-user Programming、可定制系统、低代码和无代码平台都在尝试把一部分塑造能力还给用户。
近年来，Ink & Switch 把这类方向称为 Malleable Software：人不只是软件的消费者，也应该能够以较低摩擦修改工具，让工具适应自己的思考和工作方式。大模型又补上了一块过去长期缺失的接口——普通用户终于可以先用自然语言表达目标，而不必先把意图翻译成代码或复杂配置。Geoffrey Litt 在 2023 年讨论 LLM 与终端用户编程时，强调的也是这种变化。
我更愿意把它翻译成：可塑软件。
可塑不是说软件可以随意变化，更不是每次输入一句话就临时生成一堆不可维护的代码。它描述的是另一种产品关系：软件不再把最终形态全部预设好，而是向用户交付一套可以继续组合、调整和沉淀的能力材料。
可组合，还不等于可塑
可组合软件和可塑软件很接近，但两者关注的层次不同。
可组合架构强调把系统拆成独立模块、API 和服务，再由开发者或架构师组装成不同应用。它解决的是软件内部如何更容易替换和复用。
低代码和工作流平台把组合权进一步交给业务人员，但用户通常仍然需要理解节点、连线、字段映射、条件表达式和平台自己的配置语言。它把写代码变成了画流程，却没有完全消除形式化表达的门槛。
生成式 UI 或“一句话生成 App”走得更远。它根据一次提示生成页面和代码，适合快速获得一个工具原型，但也容易把软件变成一次性产物：这次生成的应用如何继承组织权限？谁负责高风险动作？下次需求变化时，是继续演化原来的系统，还是重新生成一份？运行中形成的方法和例外又沉淀在哪里？
可塑软件要解决的不是单次生成，而是长期使用。
它至少需要同时成立五件事：
- 能力可以组合：模型、工具、Skill、服务和界面不被锁死在一个单体应用里。
- 用户可以表达意图：自然语言成为组装入口，Agent 负责把模糊目标转成可以执行的计划。
- 流程可以调整：不同团队可以选择、修改和复用自己的 SOP，而不是等待厂商开发一条新流程。
- 运行受到治理：权限、审批、版本、审计、取消、恢复和失败语义不能随着自然语言一起漂移。
- 使用能够沉淀：每次执行产生的规则、例外、决策和产物，可以进入下一次运行，而不是消失在聊天记录里。
因此，可塑软件不是更自由的提示词，而是一套既能变化、又能承担责任的软件结构。
三层系统：运行时、领域能力与组织沉淀
我最近同时在做 Silieco、DeepSeek Harness，以及 Chat2DB 的 DSH Plugin。最初它们看起来是三个不同项目，现在我越来越觉得，它们分别对应可塑软件的三个层次。
底层提供可以替换的运行能力，中层连接数据库、仿真等专业服务，上层把这些能力组织成可运行、可治理、可沉淀的工作。
DSH：把 Agent Runtime 变成可组合材料
DeepSeek Harness 基于 Cordis，采用“一切皆插件”的架构。模型适配器、工具注册表、会话日志和 Agent Loop 都是插件，不存在一个只能接受外围扩展、自己却不能替换的特权内核。
DSH 的 Profile 和 Bundle 决定一个产品如何组装，Preset 决定一次会话中的 Agent 使用哪些提示词、工具和能力。文件系统、Shell、模型、Skills、工作流、子 Agent、审批和 UI 都可以通过稳定的能力接口被替换。
这意味着我们不再需要为每一个垂直软件重新开发模型接入、Agent Loop、上下文、会话、工具调用和交互界面。通用 Runtime 成为基础材料，真正有行业差异的能力通过插件加入。
但只有插件化还不够。插件生态解决的是“有什么能力可以装”，还没有解决“某个组织如何把这些能力变成自己的工作方法”。
Chat2DB Plugin：让传统 App 成为领域能力节点
Chat2DB 已经积累了数据库连接、元数据、DataWiki、SQL 执行、数据权限、审批和审计。如果为了增加 Agent 能力，就把这些东西全部重写到 DSH 里面，不仅成本高，还会破坏原 App 已经建立的责任边界。
所以 Chat2DB DSH Plugin 做的不是迁移业务，而是授权和映射能力。
用户在 Chat2DB 中选择一个具体 Agent，DSH 得到这个 Agent 当前允许使用的数据库工具。Plugin 不读取数据库凭据，也不能扩大数据范围。每次调用时，Chat2DB 都会重新计算 Agent Capability、DataScope、DataWiki 和工具安全策略；高风险 SQL 仍然需要在 Chat2DB 中审批，并以同一个调用 ID 恢复和幂等重试。
DSH 决定下一步想做什么，Chat2DB 决定这一步能不能做、怎样执行，以及执行以后如何负责。
这使一个传统 App 从“必须由人打开页面操作的软件”，变成了“人和 Agent 都可以在授权范围内调用的领域能力节点”。App 没有消失，它只是从最终入口退到了更适合自己的位置：业务能力和控制面。
Silieco：让一次组合变成组织资产
DSH 可以运行 Agent，Chat2DB 可以提供数据库能力，但一次工作还需要属于某个组织、项目和任务。
Silieco 的作用，是把人、Agent、Task、Project、SOP、Workflow Run、Stage、Skill、Gate 和 Artifact 放进同一个协作系统。
用户可以从一句目标开始，把任务分配给人或 Agent。简单工作直接沿 Task 生命周期推进；复杂工作进入某个 Project 的 SOP，启动一次具名 Workflow Run，再由不同 Stage 约束输入、输出、所需 Skills、允许状态和决策方式。
SOP 不是一段只能由开发者维护的后端代码，而是团队可以发布、运行、微调和继续版本化的工作定义。Skill 也不是绑定某一个 Agent 的长提示词，而是可以被多个 Agent 复用的方法、脚本、模板和参考资料。
最关键的是，运行过程不会只留在一段私聊中。需求、评论、附件、Agent 执行、人工决定、Stage 变化和最终产物都进入同一份组织记录。
DSH 让能力可以组合，Chat2DB Plugin 让既有软件可以接入，Silieco 让组合后的工作可以运行、治理和沉淀。
散热 SOP 真正打通的是“关节”
回到散热仿真案例。
从产品表面看，这条 SOP 只是把需求、仿真、评审和报告串在了一起。但它真正打通的，是外部专业服务进入一次完整业务交付时最容易被忽略的关节。
Agent 展开候选空间，外部服务执行专业求解，工程师在关键 Gate 决定方向，结果和经验继续回流。
第一，需求不是一句提示词，而是一份带单位、来源、假设和缺失项的快照。用户没有明确确认关键验收条件，系统不能自己补一个看起来合理的默认值。
第二，外部仿真是长任务，不是一次同步 Tool Call。系统必须区分任务已接受、运行中、执行成功，以及工程结果通过或失败。SUCCEEDED 只表示求解任务完成，不表示散热方案达标。
第三，Agent 可以搜索候选方向，但不能代替专家做方向决定。每个候选都要包含具体动作、预期方向、风险和“需要人工批准”的标记。没有不可变的批准记录，就不能进入下一轮。
第四，每轮运行必须可比较、可回退。候选方案使用同一份验收标准与基线对比，并保留温度变化、执行状态、热判定和回退建议。
第五，报告不是模型最后总结的一段文字，而是从需求、模型校验、基线、候选、批准和复算产物中生成的可追溯交付物。
这些契约背后可以连接 Icepak、PyAEDT 或其他仿真服务。外部服务可以升级或替换，需求确认、人工 Gate、Artifact 和审计链路不必一起重写。
这就是可塑软件中“塑”与“不塑”的边界：
实现可以替换，流程可以重组，能力可以增减；但一次运行中的身份、权限、验收标准、人工决定和执行证据不能随意变化。
交付的不再是功能清单，而是一套生态
传统软件销售时喜欢列功能清单：支持多少种文件、多少个页面、多少类报表、多少个自动化动作。用户购买的是厂商已经决定好的能力集合。
可塑软件交付的东西不同。
平台首先提供一套稳定底座：Agent Runtime、身份、权限、会话、任务、审批、审计、版本和 Artifact。不同厂商、业务专家和社区开发者再提供领域插件、Skills、SOP 模板、数据服务和专业工具。最终用户根据自己的任务、团队和风险边界进行组合。
同一套底座可以被组装成散热仿真工作台、数据库 Agent、研发协作系统、投标流程或文档生产线。它们不只是换一个 Prompt 和 Logo，而是选择了不同的领域能力、工作流程、决策 Gate 和交付标准。
这里很像乐高，但又不只是乐高。
乐高积木在搭建结束后，成品基本就确定了。可塑软件还会在运行中继续学习组织的工作方式：专家为什么驳回某个候选方案，哪个验收条件经常被遗漏，什么数据访问总是需要审批，哪类失败可以自动重试，哪类异常必须升级给人。
这些信息经过确认后，可以变成新的规则、案例、Skill、SOP 或评测集。用户沉淀的不再只有业务数据，还包括“我们是怎样完成这类工作的”。
因此，平台与用户之间的关系也会变化。
软件厂商不再负责提前猜中所有需求，而是负责提供可靠的能力材料、组合机制和治理底座；领域专家负责定义专业方法、例外和质量边界；用户在真实工作中不断形成适合自己的运行方式。
交付完成不是生态停止生长的时刻，而是它刚刚开始适应这个组织的时刻。
可塑不等于失控
自然语言、动态组合和 Agent 自主执行很容易让人联想到另一种未来：每个人都临时生成自己的软件，企业里到处都是无法维护、无法解释、无法审计的一次性程序。
那不是可塑软件，而是软件碎片化。
可塑软件要真正进入企业，必须解决一个看似矛盾的问题：一方面允许每个团队形成自己的工作方式，另一方面又要确保组织能够知道谁调用了什么能力、基于什么输入、经过谁批准、产生了什么结果。
所以越可塑的系统，越需要稳定的骨架。
模型可以更换，但工具权限不能由模型自己声明；SOP 可以调整，但已经完成的 Stage 和人工决定不能被悄悄改写；Agent 可以提出候选方案，但不能自动批准自己的高风险动作；领域服务可以成为插件，但插件不能绕过原 App 的权限与审计；用户可以从自然语言开始，但最终执行必须落到明确的能力契约和结构化产物上。
我把它概括为一句话：
形态可以流动，责任必须固化；能力可以自由组合，关键决策必须留下证据。
没有前半句，软件仍然是由厂商预先凝固的成品；没有后半句，它就只是一场无法进入真实业务的生成式演示。
软件公司的产品边界正在变化
过去，软件公司把需求变成代码，再把代码封装成产品交付给用户。用户的数据可以进入软件，用户的方法却很难真正进入软件。只要工作方式超出预设，需求就要重新回到厂商的产品经理和开发团队。
Agent、Skills、插件化 Runtime、标准能力协议和组织工作系统开始改变这个边界。
未来的软件公司可能不再为每个客户交付一个最终应用，而是交付三样东西：
- 一套可靠、可治理的运行底座；
- 一组经过验证、可以组合的领域能力；
- 一种让用户把自身方法持续沉淀进去的机制。
软件仍然需要工程师，专业服务也不会消失。改变的是谁有权决定软件最后长成什么样。
过去，产品经理和开发者在交付前决定大部分形态；未来，领域专家和最终用户会在运行中参与塑造它。每一次真实任务都可能让系统更接近这个组织，而不是更接近一个抽象的“标准客户”。
这就是我理解的可塑软件：
它不是一套等待用户适应的固定功能，也不是每次从零生成的一次性 App。它是一套可被自然语言驱动、可由能力生态组合、受明确责任边界治理，并在真实工作中持续生长的软件系统。
当软件从成品变成材料，从功能集合变成能力生态，从保存业务数据进一步走向沉淀工作方法，我们交付出去的就不再只是一个工具。
我们交付的是一个组织可以继续塑造的数字工作环境。
延伸阅读：DeepSeek Harness：Agent 内核全开源，套皮就是商业软件 · 不重写 App，如何用 DSH Plugin 完成 Agent 化转型 · 别急着裁掉中层：先用 Agent 生态放大业务专家