传统软件 + Agent生态

今天在思考“传统软件在AI时代下如何加速且质量稳定”的问题时一个念头突然击中了我为什么软件必须是交付即固化的成品而不能是一座“在生长的花园”它的功能不是预先刻死的而是在每一次解决真实问题的意图驱使下“生长”出来的。这便形成了一个生态。每一次的功能都是在一次意图驱使下生长出来的形成一个工具/脚本/SKILL/MCP等等形态即可执行、可复用的知识单元都统称沉淀——这个领域下的知识沉淀、复用能力积累。它们是该领域下由意图驱动的可复用知识单元。下次相似问题再来Agent会自主决策是调用已有沉淀来高效解决还是自适应地“生长”出一个新方案再执行这个过程本身也构成了新的知识沉淀。从传统插件机制到Agent生长生态从插件机制到Agent生长生态从工程师开发插件到工程师培育Agent生长能力这并非凭空构想传统的‘插件机制’就是其演化前身以GIS数据处理平台为例为应对无尽的格式转换需求平台通过定义标准接口让插件‘热插拔’组合形成了可扩展的能力——但这依赖工程师的预先开发。所以平台的核心能力之一是可扩展性——定义好抽象的操作组件接口、提炼中间格式通过插件热插拔迭代组合出可成长的平台。而“Agent生长生态”将此往前推了一步我们无需预先开发插件只需定义好“土壤”——核心算法、工具集、领域知识等前置信息。Agent在意图驱动下自行编排、生长出能解决新问题的脚本并自动沉淀为新的“能力插件”。核心变化从开发插件到培育生长以前软件研发工程师领域专家去沉淀插件来丰富平台的能力现在Agent研发工程师 领域专家去沉淀知识由Agent生长出一个解决这类数据的工具/脚本/SKILL/MCP以上的核心变化在于人直接产出的不再是代码而是知识。过去工程师与专家合作产出的是“插件”现在他们合作沉淀的是“领域知识”而将知识转化为工具的编码与编排工作由Agent完成。最终交付给用户的平台仅仅是这套生长生态在某一时刻的“能力快照”。这意味着软件的生命力不再由版本号定义而由其背后生态的生长活力定义。可生长的Agent软件生态在这个生态中工程师的核心身份从“搭建者”转变为“园丁”其核心工作不再是编写确定性代码而是设计让软件自主生长的规则与流程。Agent则成为生态的运转核心在遇到如“将tif发布为wms”、“将shp发布为wfs”等新需求时自主决策是复用现有能力还是生长出新模块来达成目标。重构的空间功能操作与任务意图分离在我的另一篇《传统软件在AI下的落地》里明确了Agent不仅理解意图、编排既有工具。那么现在更进一步能在坚实的内核之上自行创造新工具并沉淀知识。传统交互的“孤岛困境”——比如将一个发布服务任务拆解到数个割裂界面——被彻底弥合。用户只需表达意图编排由AI完成执行则由可信的传统内核托底。与前沿Agent生态的契合当然灵感也不是空中阁楼它与当前Agent领域的几个前沿方向也有着深度共振我觉得这也是AI Native的一个探索路径。Agentic Workflow智能体工作流。Anthropic、LangChain等团队正在推动一个核心理念Agent的真正威力不在于单次对话而在于编排多步骤、多工具的工作流。文中提出的“Agent编排生成处理流程”、“自主决策复用还是生长”正是这一理念的体现。更进一步的是当前主流Agent仍停留在“编排已有工具”而文中构想的“生长出新工具”将编排能力往前推了一步。MCP模型上下文协议与可复用能力单元。Anthropic推出的MCP协议本质是让Agent动态发现和调用外部工具这与“可扩展能力”的思想完全一致。从OpenAI的Plugins到Semantic Kernel的Skills业界在“可复用能力单元”上已经形成共识。但当前这些能力仍由工程师预先开发。文中的核心洞见——将工具/脚本/SKILL/MCP统称为“沉淀”并让Agent自主生长这些能力——精准指出了当前范式的局限我们只是在用Agent重新封装传统开发流程尚未真正释放Agent的自主构建潜力。从知识检索到知识沉淀。当前Agent落地的典型方案是用RAG检索文档来增强回答。本文提出的“执行过程本身也构成新的知识沉淀”更进一步沉淀的不是静态文档而是经过验证、可执行、可复用的能力单元。这本质上是一种“可执行的知识图谱”是Agent生态从“消费知识”走向“生产知识”的关键跃迁。真实面临的问题这次是一个实验性地思考所以真实落地可能还有一定的差距我们需要结合当下的能力进行诚实分析并积极进行验证尝试以下是在实践中可以预见的几个关键挑战。生成工具的确定性验证。Agent自主生成的工具质量如何保证在GIS地理信息系统这个强规则领域一个数据转换脚本的错误可能造成严重后果。虽然本文提到了“定义验收结果、验收机制”但验收机制本身的自动化就是高门槛。一个可行的补充是建立“确定性验证层”——领域专家对生成结果的认证是能力进入“沉淀库”的前置条件。Agent可以生成方案但进入复用生态的“入池权”仍需人的把关。生态膨胀与能力冗余。如果Agent在不断“生长”新工具生态会不会走向失控当沉淀库中积累了上百个功能相似、质量参差的脚本时“自主决策调用哪个”本身就变成了难题。本文虽然提到了Agent自主决策“复用还是生长”但还需要一个反向机制——生态修剪。正如花园需要园丁修剪枝叶Agent生态也需要定期的能力去重、质量评估和废弃清理。工程师心智模型的转变。“从搭建者到园丁”是一个动人的隐喻但现实中这要求工程师放弃对代码确定性的掌控感转而信任Agent的生长能力。这不仅涉及技术工具的更新更涉及整个团队的心智转变和工程文化的重建。如何让习惯了“确定性交付”的工程师接纳“生长式交付”是组织层面的真实挑战。与传统软件工程的对接。CI/CD流水线、版本管理、回归测试——这些成熟的软件工程实践如何适配一个“生长的软件”“能力快照”可以作为交付的切面但快照的生成时机、质量门禁、回滚机制都需要在实践中逐步摸索。这不是构想层面的问题但会是在落地过程中必须回答的工程难题。总结从“开发插件”到“培育生长”从“版本号”到“能力快照”从“搭建者”到“园丁”——这些转变共同指向一个判断传统软件不会消失但它会退后为“可信内核”Agent不会取代一切但它会成为“生长的土壤和园丁”。二者的共生或许就是传统软件在AI时代下的答案。其它原始内容在我的飞书知识库中传统软件 Agent生态。我会基于一个GIS领域的“自动化闭环GIS 数据 → 处理 → 样式 → 发布 → 浏览 → 验证”这个实践场景来逐步回应这个灵感。我的AI积累主要写在飞书知识库内会持续更新迭代输出自己的想法与实践总结Being的AI积累