平台是否应该了解它生成的软件?
摘要
作者正在构建一个软件生成平台,并质疑平台是否应知晓生成的组件,主张基于制品的契约和生命周期管理。
我正在构建一个平台,用户描述任务后,平台会生成一个代理以及所需的软件:UI、API、服务和数据库。目前我面临的一个问题是平台本身应该了解多少生成的软件。我当前的方法是保持生成的服务隔离,并将制品本身作为事实来源。例如,在生成UI时,我不希望平台维护每个生成的API路由的知识。UI和后端应基于生成制品中存在的契约进行通信。平台主要应关注生命周期:构建、运行、更新和验证制品。我目前正在针对生成的OpenAPI规范进行通用测试,以检测服务之间和跨版本的破坏性变更。我很好奇其他人会如何处理这个问题。你会让平台完全不知道生成的路由,依赖制品内的契约,还是在平台层面也维护一些生成的API表示?
相似文章
平台工程仍然重要
一篇观点文章,认为即使有了AI编码工具,平台工程和代码复用仍然有价值,因为token需要成本,而复用能带来杠杆作用。文中引用了Martin Fowler关于重构的类似论点。
智能体应该是代码还是带有独立运行时的声明式实体?
作者认为,生产环境中的AI智能体应定义为具有独立运行时的声明式清单,而不是分散在应用代码中,以便实现适当的版本控制、可观测性和回滚。他们将自己的解决方案作为开源工具提供。
演进,而非重置:为自主智能体准备平台工程 2.0
分析平台工程必须如何为 AI 代理演进,从僵化的黄金路径转向可组合的、API 优先的构建块,以支持非人类身份、范围化权限和审计追踪。
编码智能体是否需要类操作系统的控制平面?我构建了一个原型并寻求批评意见。
作者介绍了“KnowledgeOS”,这是一个原型控制平面,旨在通过管理任务生命周期、防止状态漂移和确保执行证据来治理本地编码智能体。他们希望获得关于此类操作系统级抽象是否必要,或者是否属于智能体工作流中过度设计的架构批评。
AI代理是否应该能够看到应用程序实际在做什么?
讨论AI编程代理需要超越源代码的运行时感知能力,例如检查容器、端口和服务,并考虑代理应对开发环境拥有多大程度的控制权。