智能体工程的隐形技术债：10分钟造出一个 Agent，公司却要为它养一个平台团队AI前线·2026年04月27日 19:57如今，任何人都可以很容易地在本地构建一个智能体 如今，任何人都可以很容易地在本地构建一个智能体。通过一些 LLM 调用、提示和几个工具定义，这个智能体就能在几分钟内为他们完成实际的工作。但是，当这个智能体投入生产并被整个工程部门使用，涉及到真实的数据和实际的后果时，会发生什么呢？ 2015 年，谷歌发表了“机器学习系统中的隐性技术债务”。那篇论文为机器学习工程师指明了方向，并一针见血地指出了他们所面临的所有问题。文中分享的那张图片也成了经典：一个标有“ML Code”的小方框，被庞大的基础设施模块所包围。 对于智能体，我们看到了相同的模式。智能体只是画面的一小部分，我们想要命名围绕它们的所有基础设施。 智能体工程系统特别擅长积累技术债务。它们有传统软件的所有维护问题，同时还要加上一些智能体才有的问题。几乎每个员工每天都在创建新的智能体。很快，你拥有的智能体将比员工还多。 我们将智能体定义为任何具有动态决策能力的进程，它们能够通过推理和反思自主确定工具使用和执行路径。决策、推理和反思需要所有辅助性的基础设施。 构建智能体很容易。但在生产环境中，智能体代码只占系统最小的一部分。周边的一切才是真正复杂的。 在过去的几个月里，根据与工程领导者的对话和我们自己的经验，我们绘制出了围绕智能体的七个基础设施模块。每个模块是一类工作，都是人们构建演示系统时没有计划在内的。 如果你做过传统的工程项目，那么这些模块中有一些会看起来很熟悉：可观测性、集成和治理。其他模块是智能体项目独有的，例如人机回环、非确定性系统评估和智能体注册表。 让我们逐一了解下。 集    成  智能体需要连接到你实际的系统：CI/CD、云提供商、事件工具、可观测性平台、代码库、密钥管理器等。 如果不集中管理集成，那么每个团队都会自己设置智能体连接。 想象一下，一个有 30 个团队、200 名工程师的工程组织，每个团队都有多个智能体。每位工程师都为编码智能体生成自己的 GitLab PAT，为数据智能体生成 Snowflake 凭据，为部署智能体生成 Kubernetes 服务账户，为事件智能体生成监控令牌。 那将是数百个集成点，每个都需要单独配置、单独调试，并且都有自己的有效时间表。 当每个开发人员都设置自己的凭据时，每个智能体使用的 Token 不同看到的数据就不同。一个开发人员的 GitLab PAT 可以访问所有代码库，其他人的范围则限定在他们自己团队。智能体类型相同，但每一个都有一个完全不同的组织视图。 或者，当 GitLab 的 API 有重大更改时会发生什么？每个独立创建连接的团队都要调试相同的问题（或向平台团队提交工单）。三个团队在周一解决了这个问题，到周三又有两个团队。有个团队过了一周都没有注意到，因为他们的智能体只在事件期间运行。 通过这些集成传递的内容也很重要。当三个团队通过不同的路径连接到相同的数据源时，对于同一个问题，他们的智能体会得出不同的答案。如果一个团队的集成拉取了 30 天的部署历史，而另一个团队的集成显示了过去 3 年的所有内容，则他们的输出就会不同。 现在，MCP 是大多数团队将智能体连接到工具时采用的方式。但我们不要将 MCP 与集成混淆。MCP 为智能体提供了一种标准的工具调用方式。它并不管理调用的凭证，返回数据的范围，或者当另一端的 API 发生变化时会发生什么。 集成方面的隐性技术债务可能像下面这样： 一个集成的身份验证令牌在周五晚上到期，一个事件智能体默默地停止了工作，而直到周一都没有人注意到这个情况。 五个团队各自维护自己的 GitLab 连接，权限和范围各不相同，都不知道其他人的存在。 当一个集成升级其 API 时，每个团队都要分别调试其连接。 上下文湖  智能体的好坏取决于它们可以引用和使用的上下文。它们需要两种上下文。 运行时上下文：如何在智能体执行期间向它们提供准确的上下文？ 运行时上下文是智能体在特定执行期间需要的实时数据，例如有关服务的信息，谁拥有这些信息，以及最近部署了什么内容。这与人类在编码或解决事件时使用的数据相同，但于智能体而言更容易获取。 想象一下，一个编码智能体接手了一个工单，为一个服务添加重试机制。它需要知道：服务使用什么语言和框架，这个组织中的其他服务如何处理重试，它调用的下游服务归谁所有，以及超时设置最近是否有过更改。 有一些团队在 Markdown 文件中管理他们的运行时上下文：agents.md，.cursorrules 和技能文件。 对于静态指令，像如何格式化提交或使用哪个 Linter，使用 Markdown 文件就很好。但运行时上下文是不断变化的：服务所有权转移；依赖项被添加；配置值更新；每小时都有部署。一个基于.md 文件运行的智能体说“checkout-service 归 Payments 团队所有”，它不知道这个服务的所有权在上周二转移到了 Commerce 团队。文件在编写时是准确的，等到智能体读取的时候，可能就不准确了。 决策痕迹：如何帮助智能体从自己过去的工作或其他智能体的工作中学习？ 决策痕迹是之前做过的事情（由人类或智能体完成），是关于为什么做出决策，以及之后发生了什么的历史。没有这个历史作为参考，每次智能体都是从零开始运行。想象一下，智能体打开一个 PR 来修复一个不稳定的测试。它不知道上周另一个智能体尝试了相同的修复，这个 PR 因为会破坏下游契约而被拒绝，而团队已经决定完全弃用该测试。因此，它重新打开了相同的 PR。没有决策痕迹，智能体会重复人类（或智能体）已经解决的错误。 一个解决过 50 个事件的智能体已经看到了新智能体没有看到过的模式，比如哪些修复有效，哪些会导致回归，以及哪些服务在部署后变得脆弱。没有痕迹，这些知识会在每次运行后消失。当多个智能体在同一个系统上操作时，它们无法看到彼此的历史。 LLM 提供商开始通过可以跨团队共享的 memory.md 文件来解决这个问题。但当你有几十智能体在运行时，债务还是会出现。你需要找到一种可靠的方法将该记忆（或只是它正确的部分）提供给特定的智能体。 在上下文湖中，隐性技术债务可能像下面这样： 上下文陈旧过时、支离破碎且无人负责。 公司标准存在于维基中，而智能体基于 agents.md 文件运行。 智能体没有学习其他智能体为什么以及如何解决一个问题，又不了解它们犯过的错误。 智能体注册表 让我们了解存在哪些智能体。 组织结构图在动态变化。现在不仅仅是人，还有数量为 5-10 倍的智能体。它们是由所有的人类员工在每天的工作中创建的。它们运行在没有护栏的环境中，它们可以访问关键基础设施，它们正在做决策。它们也分布在 Claude Code、Cursor、n8n、zapier、Notion、AWS、GCP 等工具中。 典型的模式是这样的：一个工程师构建了一个分诊智能体，其团队开始在它的帮助下处理事件。另一个团队构建了自己的版本，因为它不知道第一个智能体的存在。第三个团队也构建了类似的东西，但是连接到不同的工具，有不同的权限。 在一个有 20 或 30 个工程团队的公司里，你很快就会遇到责任重叠、行为冲突以及依赖项不可见的智能体。在智能体可以在团队之间共享之前，你首先需要知道它们存在。 向智能体传达指令 在实现了智能体的可见性之后，你还需要为它们提供相当于员工手册的东西：标准、技能以及期望它们如何操作的指令。 如今，工程师们都是独立地为他们的智能体创建技能文件。问题是，当它们分散在不同的存储库中，没有一个集中的视图时，团队最终会创建出重复或不准确的技能。他们会经常与平台分发的上下文相矛盾。平台团队比个别团队更有洞察力，他们更知道在技能文件中写什么。 那么，该如何将一致但个性化的编码规则、命令、技能和钩子传递给正确的智能体呢？ 这些信息甚至可能需要多个层次： 公司范围内适用的标准（安全编码、提交规范） 特定于存储库的指令（“在这个存储库中，事件是这样创建的”） 或者针对工程师子集的团队级规则 你需要找到一种方法，将这些信息可靠地传递给成千上万的智能体，确保正确的指令能够到达正确的智能体。 智能体创建 假设你已经可以看到现有的大多数智能体，并向它们传递了指令。下一个问题是如何控制智能体的新建过程，而不拖慢团队的速度？ 现在，这个责任落在了平台团队身上。 就像软件目录中的服务一样，智能体应该有标准化的属性，并且应该与公司的其他实体建立连接，比如其他智能体、团队、服务、部署等。 如果没有模板，你就会遇到你刚刚解决过的问题。一个工程师启动了一个智能体，没有所有者，没有生命周期状态，也没有它所操作的服务的连接。它为他们工作，但其他人都不知道它的存在。六个月后，有人发现它在生产环境中运行，使用了过期的 Token，却没有办法联系到构建它的人。 一个工程师启动了一个智能体，没有所有者，没有生命周期状态，也没有与它操作的服务的连接。这对他们来说有效。其他人都不知道它的存在。 智能体创建应该遵循标准模板。这并不是说人类员工创建智能体时应该放慢速度。恰恰相反，与他们单独创建相比，一个标准化的智能体创建过程，可以帮助他们更快地达成高质量的工作。 应该允许工程师从他们的工作站创建智能体。如果他们在 Cursor 中工作并且需要启动一个智能体，那么他们应该能够从那里做到这一点，而不是从其他地方。也就是说，你作为平台工程师的工作，是确保在任何地方创建的智能体都遵循你的创建过程。 模板不会限制智能体做什么。它只是确保每个智能体都具备基本要素：所有者、描述、它使用的工具、它连接的服务以及生命周期状态。这样，从第一天起就可以对它们进行管理，而不是后续再去费力地追查。 在智能体注册方面，隐性技术债务可能像下面这样： 智能体不可见 团队正在创建重复的智能体 上下文过时 当 CISO 要求进行智能体审计时，却没有一个列表可以入手 没有一个明确的将智能体提升到生产应用状态的方法 没有版本控制、回滚或过渡环境 度    量  你怎么知道你的智能体是否在工作？这取决于谁在问。 SRE 想知道智能体做了什么。机器学习工程师或产品经理想知道它是变得更好还是更糟了。工程副总裁想知道它是否值得花钱。最终用户想知道智能体是否根据他们的反馈进行了学习。 所以，虽然每个人都想对智能体做一些度量，但他们想要度量的东西并不一样。 1. 怎么知道智能体在做什么？ 这是 可观测性。 事件、跟踪信息和日志记录了智能体所采取的行动、访问的数据，以及它是否仍在正确地运行。工程团队了解传统系统的可观测性，但对于智能体，观测面更广。 假设你有一个智能体，它可以自动处理 Jira 工单。当它收到一个 Jira 工单时，它会读取服务目录，找出相关的存储库，通过 GitHub 集成拉取最近的提交，使用编码智能体生成一个修复，然后回到 GitHub 打开一个 PR，并请求它从软件目录中找到的服务所有者进行审查。如果修复对某些东西造成了破坏，哪个步骤出了问题？它拉取了错误的存储库吗？误读了所有权？生成了糟糕的代码？ 如果你不能完整追踪整个链条中的所有动作，那问题排查的难度会大大增加。 2. 当提示、技能、工具和模型发生变化时，怎么知道智能体是否变好了还是变糟了？ 这就是 评估。 在标准软件工程中，你可以编写一个单元测试，然后判断是否输出了一个确切的字符串。在智能体工程中，每个响应都不同，你需要采用一个不同的方法。 通过一个简单的问题进行评估：在你改变一些东西（比如提示或模型）之后，智能体是否仍然表现得很好？ 如果没有一种方法来跟踪这一点，更改就会在未经测试的情况下发布，输出质量可能会悄无声息地降低。就像用 Opus 替换 Sonnet，你的 PR 审查智能体开始批准它以前标记过的东西。 3. 怎么知道智能体是否真的做出了业务贡献？ 这是 业务影响。 在今年的每次财报电话会议上都会有人问：“AI 对你的业务有什么贡献？” 大多数工程领导者都回答不了，最终，他们是负责度量智能体成本和 ROI 的人。 在整个过程中，追踪支出是相对比较简单的一部分工作。你可以追踪 Token 使用情况、API 调用次数以及每个智能体、每个团队的计算成本。 投资回报率（ROI）则比较难以衡量。智能体解决了多少工单？它节省了多少工程时间？它是否真的减少了平均故障修复时间（MTTR），还是只是转移了工作量？这些数字更难以收集，也更难以让人信服。如果你只能做成本方面的展示而不能清晰地展示 ROI，那么这会是一个糟糕的对话。 4. 如何向智能体反馈它们的工作？ 这是 反馈循环。 当智能体生成一个 PR、解决一个工单或编写一个根本原因分析（RCA）报告时，负责审查输出结果的人类是接受了输出还是进行了更正？这通常用赞成或不赞成来管理，但有时候，人类的回应本身就是反馈（比如“不，再试一次，但改为 X”）。 这对于改进智能体至关重要，比评估更重要。处于演示阶段的智能体要么不收集这些信号，要么不采取相应的行动。 在度量方面，隐性技术债务可能像下面这样： 不知道智能体性能是随着时间提高还是下降，以及与什么相比 当提示或模型变化时，无法衡量发生了什么 领导层要求 ROI，但你给不出明确的答案 未能收集使用智能体的人类的反馈 人机回环 在完全手动和完全自动化之间有一个区域。在一端，人类做所有事情。在另一端，智能体不做询问就采取行动。大多数有用的智能体处于中间的某个地方，它们的确切位置取决于行动、环境和风险。 人机回环是让你可以安全地将智能体趋近自动化的机制之一。它让你定义检查点：这个行动需要批准，那个不需要，这个取决于环境。智能体自动运行，但人类要在执行前确认高风险决策。 例如，系统部署智能体在测试环境中可以自由运行，但在生产环境中需要批准。它可以在营业时间内完全自主，但在凌晨 3 点则需要人类参与。规则是有条件的，因智能体、行动、环境和团队的不同而不同。 当你的演示中有一个智能体时，你可以将批准检查点硬编码为一个 if 语句，部署前由它在 Slack 上发出通知。当 20 个团队中有 100 个智能体时，硬编码的批准逻辑将无法扩展。每个团队都实现了自己的版本。一个团队的智能体在没有经过批准的情况下回滚生产。另一个团队的智能体需要三次批准才能做同样的事。没有一个集中式的定义，没有人知道哪些智能体可以独立行动，哪些不能。 然后是对审批本身的编排。谁会收到通知？通过什么渠道？如果没人回应，超时时间是多少？如果审批人在度假怎么办？如果一个智能体的审批通过 Slack，另一个通过电子邮件，第三个通过自定义 UI，那么你现在就有三个审批系统需要维护。围绕审批的逻辑变成了独立于智能体存在的主要技术债务。 如果我们扩大视野，人机回环也关乎了解智能体内部发生了什么。随着工程师进入更偏管理性的角色，他们将需要一个控制平面来查看正在进行的工作，启动智能体的工作，识别哪些智能体需要关注，并在需要时采取行动。 这很重要，因为人机回环是你大规模应用变化所依赖的方法（如今的公司都是要么改变，要么消亡）。为了在新工作中取得成功，工程师们需要能够看到智能体的工作，就像过去可以看到他们的代码如何工作一样。如果一个团队能够观察智能体如何处理其前十个部署（可以看到每一步，审查每个决策，并在需要时进行干预），他们便会信任那个智能体；如果不能，就不会。 人机回环中的隐性技术债务可能像下面这样： 硬编码的审批代码无法从一个集中的地方进行更改 一些智能体在不需要审批的情况下运行，其他智能体则需要经过太多的批准 通过电子邮件、Slack 和自定义 UI 进行审批的多个审批系统，相互之间不兼容 没有一个共享工作区，让团队可以看到他们的智能体在做什么，并在必要时进行干预 治   理  当人类工程师需要访问生产数据库时，需要经过一个流程。他们提交请求，有人批准，然后访问范围被限定和记录。这个过程可能需要一个小时或一天，但谁有权访问什么以及谁做了什么，都有审计日志记录。 当工程师在本地创建智能体时，它在运行时使用的通常是其创建者设置的凭据：他们的 API 令牌、他们的服务账户、他们的云权限。这个范围很有可能没人审查。 智能体的治理规则要具体： “回滚服务，但只有在出现高严重性事件时。” “部署到生产环境总是需要手动批准，不管是什么智能体触发的。” “从外部系统拉取数据的 RCA 报告应该只对那个服务的所有者可见。” 平台团队需要在一个地方集中定义这些规则并应用于所有智能体。 治理的另一面是执行。假设你发现了一个内部 API 的漏洞，需要立即阻止所有智能体调用它。你能吗？一个安全工程师应该能够在一个地方禁用一个工具，并让它自动在所有智能体中被禁用。大多数公司并不具备这种能力。 你不能总是从一开始就把访问权限搞得严丝合缝。事情可能会出错，一旦出错，你就需要知道发生了什么：哪个智能体采取了行动，它访问了什么数据，使用了什么凭证，以及谁触发了它。如果是在本地创建的话，大多数智能体设置都不会产生这样的审计跟踪记录。在本地运行的智能体会继承其创建者的凭证，它所采取的每一项行动看起来都是工程师的个人工作。如果三个智能体共享一个服务账户，你就无法判断是哪个智能体发起的调用。如果一个代智能体在修改生产配置之前需要经过另外两个智能体，那么审计日志可能会只显示最终的写入操作，而不显示推理、上下文或导致这一行为的决策链。 治理的另一个方面是成本治理。智能体往往会继续工作，而不管它们累积了多少成本。当工程师们在本地创建智能体时，他们可能不会考虑设置成本限制。 一个陷入重试循环或循环推理的智能体会持续消耗 Token 达数小时之久，直到有人手动终止它，或者直到从月度账单上看到了因此造成的损失。大多数团队都可以告诉你他们的 LLM 总支出，但几乎没有哪个团队能够按智能体、团队或用例进行成本分解。而且，团队也应该能够很容易地看到他们的成本状况。因为当领导层询问智能体的运行成本时，工程部门需要能够给出一个答案。 在智能体治理方面，隐性技术债务可能像下面这样： 一个不应该在生产环境中运行的智能体访问了生产数据 一个 RCA 智能体将敏感的服务数据发布到了共享频道 一个智能体在公共论坛发布 PII（Personal Identifiable Information） 无法从一个地方禁止所有智能体使用一个工具 没有智能体做了什么或为什么做的审计跟踪信息 编   排  大多数智能体工作流不仅仅涉及智能体。它们混合了智能体、工具和人。债务不在于个别步骤，而在于发生在它们之间的事情：路由、故障处理和所有权。 节点之间有什么出了问题 以上述事件响应工作流为例。一个警报被触发，一个分诊智能体接手调查，并确定根本原因是部署问题。它把事件移交给一个部署智能体，后者回滚所做的更改。然后由一个验证智能体检查修复是否有效。 想象一下，分诊智能体出错了。真正的原因是数据库超时，而不是糟糕的部署。部署被不必要地回滚，而数据库问题仍然存在，警报继续被触发。最终，工程师介入进来，从头开始调试，不过现在，他们还得处理不应该发生的回滚。这次故障并非悄无声息。工作流自信满满地执行了错误的操作，而无人能查明错误决策究竟是在哪里做出的。 实践中的编排债务可能就是这个样子。不一定是工作流停止，而是做了错误的事情并且难以追踪。 你后来新增的每个问题类型，比如安全事件、配置漂移或依赖关系错误，都会使路由更难测试和解释。这些更改本身都不难。但当没有人能决定它们如何连接时，它们每次的连接方式都会有所不同。 与传统工作流编排的不同之处 工作流编排并不新鲜。多年来，团队一直在 CI/CD 管道、Airflow 和 Step Functions 中将多个步骤串联在一起。那为什么智能体编排是一个不一样的问题呢？ 传统工作流是确定性的。步骤 A 产生已知的输出，步骤 B 消耗它。你可以测试每条路径，因为你知道每条路径。智能体工作流在链路中引入了以前没有的非确定性。当你用一个可以进行问题推理的智能体替换运行手册时，下游每个步骤都变得不可预测。你不能测试每条路径，因为你不知道每条路径。 智能体之间也没有契约。服务 API 有模式和通过版本进行管理的端点。两个智能体相互传递信息时使用的是提示和自然语言。“接口”是模糊的。一个智能体的模型更新或提示更改可能会改变其输出，从而对链路中的下一个智能体造成破坏。 举例来说，部署管道应该是完全确定性的。触发器被触发，系统识别出问题严重程度，将内容部署到预发布环境，经人工审批后，再部署到生产环境，最后由验证智能体检查系统状态。这些步骤是预先定义好的，顺序是固定的，而且风险很高，因此你需要采用这种方式。 本质上，事件响应工作流是非确定性的。根本原因可能是糟糕的部署、数据库问题、配置错误或没有人见过的东西。智能体必须调查并决定接下来会发生什么。 大多数工程团队都需要这两种工作流。问题在于没有一个通用的规则来决定何时使用哪一种。一个团队会将所有分诊结果直接发送给编码智能体；另一个团队则要求在进行任何自动化修复之前必须经过人工审核。这两种做法原本各自为政，直到某次事件需要跨团队协作时，两种方法才发生了冲突。 谁拥有工作流？ 即使每个智能体都有一个所有者，那也是不够的。编排本身还需要一个所有者。 当一个智能体修改服务，并且出现问题时，谁负责？是智能体的所有者还是服务的所有者？当一个工作流程跨越三个团队时，哪个团队对结果负责？当链路中的一个步骤失败时，是失败的智能体负责去重试，还是工作流负责重新规划路线？ 这些都不是单纯的理论问题。凌晨 2 点，当一个由智能体驱动的工作流走错了方向，三个团队在会议室里试图弄清楚，问题是谁的智能体在做什么操作时出现的。单个步骤的故障很容易排查。但要找出三步之前哪个决策导致工作流走上了错误的路径——这需要一种追踪机制，而大多数组织尚未建立这种机制。 在智能体编排方面，隐性技术债务可能像下面这样： 工作流中的一个智能体中途失败，直到下游影响显现出来才有人发现 没有办法从一个跨智能体的决策追踪到原始触发器 一个工作流跨三个团队，但没有团队对结果负责 一个智能体中的模型或提示更改悄无声息地破坏了链路下游的一个智能体 当债务来袭  这种隐性技术债务在特定的时候被触发会变得让人头疼。 在探索阶段，无所谓债务。一个工程师，一个智能体，很有效。然而，当一个团队开始真正使用智能体时，集成和上下文会是首先出问题的地方。一个智能体访问了它不应该看到的客户数据，因为没有人限制访问凭证。一个智能体对服务所有者做出了猜测，因为它没有相关的上下文。 当多个团队独立运行智能体时，债务积累会更快。智能体注册、度量和人机回环等需求会同时出现。在这个阶段，团队大约 50% 的精力将用于构建周边基础设施。 在达到生产规模（智能体嵌入到工程组织的大部分工作流）时，治理和编排成为优先事项。有些公司看到了这一点。一位架构师告诉我，“根据经验，我们知道混乱将在所难免。我们将从第一天起就设法避免它。”有些人则是吃一堑长一智：一位平台工程副总裁发现，各团队在各自为政地开发相同的智能体程序，待系统变得杂乱无章后，才不得不回过头来建立治理机制。两者最终都会构建相同的基础设施，但其中一方却要为此付出双倍的代价。 这种情况以前在微服务中出现过  这似乎和微服务的发展历程类似。每个团队选择自己的技术，做自己的基础设施，最终有人不得不站出来创建标准。如今，围绕智能体程序，又一场平台工程的变革正在上演。 平台工程曾经是一个以速度为导向的举措：自助服务、减少工单量以及为新服务搭建框架。对于智能体，速度仍然是重点，平台团队正在疲于追赶。工程师们不会等待。他们会在需要时随时在 Cursor 或 Claude Code 中启动新的智能体。平台团队的第一项工作是确定已经存在哪些智能体，并将它们置于控制之下。只有这样，他们才能做他们一直在做的事：使其他人能够更快、更安全、更容易地创建和使用它们。 有一个 DevEx 团队向我描述了他们的新角色：“我们不会是设计和创建智能体的人。我们所做的是确保开发人员知道如何使用它们，能够适当地交互，并帮助更多团队创建自己的智能体。” 我们该做些什么  从可见性开始。审计 GitHub 组织，查找与 AI 相关的工作流和操作。检查你的团队在 Claude、OpenAI 或 Bedrock 上有多少活跃的 API 令牌。查看你的工作流工具，看看是否有任何带有 AI 节点的组件。目标不是创建一个完美的清单，而是做一个初步统计。 更棘手的问题在于如何就“什么是智能体”达成共识。GitHub Actions 自动化 是智能体吗？Claude Code 的定时任务是智能体吗？包含 AI 节点的 n8n 工作流是智能体吗？在对它们进行分类之前，你需要先制定一个可行的定义。这个定义不必完美无缺，但你的组织必须就此达成一致。 还有集中化与民主化的问题。平台团队应该构建一切，然后开发人员消费吗？还是说平台团队应该提供护栏，而由各团队构建自己的智能体？这两种模式都存在。这可能取决于你的企业文化能容忍多少管控。 你现在就可以构建这个基础设施，或者等智能体泄露客户数据、一夜之间烧掉 300 美元的 Token，或者悄无声息地回滚没有人要求它处理的生产服务之后再构建它。无论如何你都会构建，唯一的问题是在痛苦之前构建，还是在痛苦之后。 原文链接：https://thenewstack.io/hidden-agentic-technical-debt/ 本文最初发布于 THENEWSTACK 博客。 本文来自微信公众号“AI前线”，作者：Zohar Einy；译者：平川：策划：Tina ，36氪经授权发布。 该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。