你的智能体是代码。别再像管理文档一样治理它们。
摘要
本文认为,企业中的AI智能体由技能、工具和MCP服务器等代码构件组成,因此应当像管理软件代码一样对其进行治理,而非将其视为文档或审批清单。因为智能体本身不稳定,而底层技能是可复用且稳定的。
暂无内容
查看缓存全文
缓存时间: 2026/08/10 07:24
# 你的 Agent 是代码。别再把它们当文档来治理了。
这个季度,你们公司的某位高管一定会要求提供一份生产环境中所有 AI Agent 的清单。最终汇总回来的数字比所有人预期的都要大。其中大部分是由从来没有提交过工单的人构建的,没有人维护这份清单,而且截止日期是按周来计算的。无论谁负责这个问题,最终都会得出同一个结论:手工维护的登记册根本跟不上 Agent 的创建速度。
这种恐慌是真实的。但它触发的应对方案却瞄准了错误的单元。要找到正确的单元,得先从为什么这个需求会同时出现在所有地方说起。
一年前,
相似文章
AI代理重现了“rockstar developer”问题,只是速度更快
该文章将AI代理与“rockstar developers”进行对比,他们编写巧妙但难以维护的代码,指出AI代理缺乏对自己行为的记忆。它建议使用可见的约定,如AGENTS.md、ADRs和测试,以使AI代理生成的代码对团队来说易于理解。
智能体应该是代码还是带有独立运行时的声明式实体?
作者认为,生产环境中的AI智能体应定义为具有独立运行时的声明式清单,而不是分散在应用代码中,以便实现适当的版本控制、可观测性和回滚。他们将自己的解决方案作为开源工具提供。
我们把AI当作魔术而不是软件对待,这让AI智能体变得难以维护。
文章认为,当前的AI智能体框架将智能体视为黑箱,导致其难以维护,并提出了一种基于Git的原生架构(Lyzr GitAgent、OpenGAP),在该架构中,智能体逻辑以平面文件的形式进行版本控制,并通过拉取请求实现回滚和可审计性。
@bibryam: 使用代理,保持主导权. https://devindickerson.dev/posts/using-agents-keeping-agency/…
一篇博客文章警告,AI 编码代理通常会默认选择流行但不适用的技术,导致技术债务,并敦促开发者在架构决策中保持主导权。
@rohanpaul_ai: 这篇来自Meta、斯坦福和伊利诺伊的调研论文认为,当代码成为AI智能体的主要工作层时,它们的效果更好…
这篇来自Meta、斯坦福和伊利诺伊的调研论文认为,当代码被用作AI智能体的主要工作层时,它们表现更好,将代码视为推理、行动和建模的环境。作者引入了‘智能体框架’的概念,包含工具、内存、沙箱和反馈循环。