ARTICLE · 1267129
AI智能体爆发,软件工程迎来新挑战
AI 能走多远，不只取决于模型多聪明 还取决于工程师能否解决智能体时代的四道新难题
—— Anthropick 平台负责人 Katelyn Lesse 于10月25日发表博客，讨论多智能体系统兴起后，软件工程面临的基础设施、身份与权限、安全隔离、监控与紧急停止等新挑战。 ——
随着 AI 模型越来越强，代码生成越来越成熟，一些工程师开始担心：如果 AI 能够完成越来越多的编程任务，软件工程师还有什么不可替代的价值？
软件工程师正在经历一场身份危机。有人因此感到焦虑，也有人享受这场变化。
在 10 月 25 日发表的一篇文章中，软件工程师 Katelyn Lesse 却比较乐观，他认为未来一两年，AI 能力的进一步释放，很大程度上取决于软件工程师能否解决一批新的工程难题。
AI 能够做到什么，不仅取决于模型有多聪明，还取决于人类为它构建了怎样的运行环境。
尤其是当 AI 不再只是一个等待人类提问的聊天机器人，而是变成成千上万个能够长期运行、彼此协作、自主调用工具的智能体时，软件工程将迎来一片全新的问题空间。
01｜从一个 AI，到成千上万个 AI
AI 智能体（AI Agent）的发展，大致经历了几个阶段。
最初，智能体主要以聊天形式工作，人类提出问题，AI 给出回答，整个过程由人类主导。
后来，模型能力增强，能够处理更复杂的任务，并连续工作更长时间。智能体开始进入云端运行环境，可以调用工具、执行代码，并在较长时间内自主推进任务。
与此同时，多智能体系统（Multi-Agent System）开始发展。
一个常见的做法是设置一个协调者，由它把复杂任务拆分成若干子任务，再交给不同的智能体执行。其他智能体还可以承担评审、提出建议等角色，帮助改进最终结果。
这已经不只是让 AI 回答一个问题，而是在构建一个能够分工合作的 AI 团队。
而更令人期待的下一步，是让大量智能体持续运行，协同解决科学研究、技术发现和硬件设计等高难度问题。
想象一下：数千个 AI 智能体同时参与一项研究，有的查阅资料，有的提出假设，有的编写和运行实验代码，有的检查结果，还有的负责评估其他智能体的结论。
它们能够持续工作数天甚至数周，不必每一步都等待人类指令。
这样的系统有可能大幅提高科研和工程工作的效率。
但问题也随之而来：如果真的有数千个智能体同时工作，现有的软件基础设施能否支撑它们？它们如何获得权限？怎样防止恶意指令传播？一旦系统失控，又该如何及时叫停？
这些不再只是模型能力问题，而是新的软件工程问题。
02｜第一道难题：现有基础设施不适合 AI 智能体
过去，许多软件系统主要运行的是相对稳定的应用程序。
例如，网站服务可以部署多个相同的实例，用户请求到来时，由系统将请求分配给不同实例。对于需要保存状态的服务，也可以通过相应的机制管理其运行状态。
Kubernetes 等容器编排技术，就是为这类工作负载提供基础设施的重要代表。
但 AI 智能体的运行方式与传统应用存在明显差异。
一个智能体可能需要保存自己的任务进度、上下文和中间结果。它可能运行一段时间，然后等待模型推理、外部工具、其他智能体或人类的响应，再继续工作。
等待期间，它未必需要持续占用计算资源；任务恢复时，却又可能需要迅速启动。
不同任务的需求也不一样：有的要求快速启动，有的希望尽量降低计算资源浪费，有的则需要在短时间内扩展到极大的规模。
当数千个智能体同时启动、暂停、恢复和相互调用时，基础设施面临的压力就与传统应用大不相同。
因此，工程师需要探索更适合智能体的运行时、文件系统、计算资源管理和隔离机制。
如今，一些 AI 基础设施公司正在开发新的文件系统与沙箱方案，Google 团队也在构建名为 Agent Substrate 的新型运行环境。
这意味着，AI 时代的基础设施创新不只是购买更多 GPU、部署更大的模型，还包括重新设计智能体运行、保存状态、调度任务和使用资源的方式。
03｜第二道难题：AI的身份与权限如何管理
当只有一个 AI 助手回答问题时，权限管理相对简单。但如果数千个智能体共同工作，它们能够访问不同系统、调用外部工具、读取文件，甚至执行具有实际影响的操作，身份和权限就成为不可回避的问题。
这里需要区分两个概念：身份认证与权限授权。
身份认证要回答的是：执行这个操作的究竟是谁？
权限授权要回答的是：这个主体究竟可以做什么？
3.1 如何确认操作来自哪个智能体
在传统的软件服务体系中，已经有比较成熟的身份管理机制。例如，系统可以为不同服务分配独立身份，并使用有效期较短的凭证进行认证，而不是让所有服务长期共享固定密钥。
这些技术也可以应用于 AI 智能体。如果某个智能体修改了文件、调用了接口或执行了某项操作，系统应该能够追溯到具体的智能体，而不是笼统地将操作归到某个人或某个 AI 平台名下。
但这只是第一步。
3.2 AI 借用人类身份，责任如何划分
许多智能体需要代表人类完成工作。例如，用户授权 AI 助手访问自己的文件、邮件或业务系统，让它整理资料、修改文档或执行某些任务。
此时，智能体可能使用与用户相关的身份和凭证访问系统。
问题是：如果一项操作由 AI 执行，系统能否清楚地区分这是用户亲自完成的，还是 AI 代替用户完成的？
这就涉及到更深层问题：授权与同意。
假设一个 AI 智能体需要连续工作两周，期间可能执行数百项操作。人类不可能每次调用工具都亲自确认，否则自动化的价值就会大打折扣。
但如果一开始就授予它过于宽泛的权限，又可能带来风险。
工程师需要设计更细致的权限机制：哪些操作可以自动执行，哪些必须征得人类同意，授权是否有时间限制，以及当任务目标发生变化时，原有授权是否仍然有效。
3.3 智能体之间如何建立信任
还有一种情况：智能体不再只是借用人类身份，而是拥有自己的身份，并与其他智能体协作。
这时，一个智能体向另一个智能体提出请求，后者应该如何判断这个请求是否可信？
即使请求来自一个经过认证的智能体，也不意味着它提出的每项要求都合理，更不意味着它有权要求其他智能体执行任何操作。
身份认证解决的是"你是谁"，却不能自动解决"我是否应该相信你"以及"我是否应该照做"。
当多智能体系统规模不断扩大，这些问题将变得更加复杂。
04｜第三道难题：安全漏洞与恶意指令会被放大
多智能体系统不仅需要管理权限，还需要面对传统软件安全问题的升级。
需要警惕的是，核心软件中的漏洞如果不能及时修复，在大规模智能体环境中可能产生更严重的后果。
设想一个系统中运行着数千个长期工作的 AI 智能体。它们会编写代码、执行程序、读取外部网页、处理其他智能体提供的内容。其中任何一个环节都可能成为攻击入口。
例如，某个智能体执行了包含恶意代码的程序，或者读取了经过精心设计、试图诱导 AI 违背原有任务要求的内容。
如果系统缺少足够的隔离措施，攻击者就可能借此影响其他智能体，甚至进一步控制整个工作流程。
这里面就牵扯到提示词注入（Prompt Injection）问题。
攻击者可能在网页、文档或其他外部内容中嵌入恶意指令，试图让 AI 将这些内容误认为应当遵循的命令。
在单个 AI 会话中，这已经是一项重要的安全挑战。在多智能体系统中，风险可能进一步扩散。
一个被攻陷的智能体，可能把恶意指令传递给其他智能体。如果这些指令又被写入共享记忆，未来启动的智能体可能继续读取并信任它们。
结果是，攻击不再局限于最初受到影响的那个智能体，而可能沿着协作关系传播。
这就是影响范围扩大问题：一个智能体遭到攻击，究竟会危及整个系统中的多少部分？
因此，工程师需要为不可信的代码和内容建立更严格的隔离机制。例如，利用沙箱（Sandbox）限制程序的运行环境，控制它可以访问的文件、网络和系统资源；同时加强对操作系统内核、浏览器、运行时和常用软件库的安全加固。
这里的关键不是假设 AI 永远不会犯错，而是确保即使某个智能体犯错或遭到攻击，也不会轻易影响整个系统。
真正可靠的系统，不能只依赖 AI 自己遵守规则，还必须在技术架构上限制它能够造成的损害。
05｜第四道难题：如何监控 AI，并在必要时真正叫停
假设一个多智能体系统已经具备了足够的计算资源、完善的身份管理和严格的安全隔离。是否就可以放心让它连续工作数周？
还不行。
系统还必须能够持续观察智能体正在做什么，并判断它们是否偏离了预定目标。
传统软件监控通常关注运行状态、错误日志、性能指标和请求调用链等信息。多智能体系统则需要更完整的可观测性。
例如，当一个任务经历了多个智能体的接力处理，工程师应当能够追踪整个过程：哪个智能体发起了任务，任务被拆分成了哪些子任务，哪些智能体调用了什么工具，又是什么原因导致最终结果出现偏差。
一个已经落地的方向是 OpenTelemetry（OTel）分布式追踪，其核心理念是：智能体不能修改自己的追踪记录，也不能修改其他智能体的记录。这一点非常重要。
如果系统的执行者能够随意篡改记录，那么监控机制就可能失去意义。出了问题之后，工程师甚至无法可靠地还原事情是如何发生的。
另一个关键要求是紧急停止机制。
系统需要具备真正有效的"停止开关"（Kill Switch）。当监控系统发现严重异常时，应当能够触发停止操作，让整个系统停止执行，并撤销或切断相关凭证，防止智能体继续访问外部资源。
但这里还有一个更难的问题：系统究竟怎样判断自己正在走向错误的方向？
智能体可能反复尝试解决一个问题，即使多次失败也不肯放弃。例如，它持续尝试访问一个不在允许名单中的网络域名。
这种行为可能源于恶意活动，也可能只是因为智能体误以为访问该域名是完成任务的必要步骤。
从外部行为来看，两者可能非常相似。
如果监控系统过于敏感，就可能频繁中断正常任务；如果过于宽松，又可能错过真正的危险。
因此，工程师不仅需要能够记录行为、发现异常和停止系统，还需要研究如何判断异常行为的性质，以及何时应该介入。这涉及监控、风险评估、权限约束和运行控制等多个方面。
06｜AI 越强，软件工程师越有价值
回到最初的问题：当 AI 越来越擅长写代码，软件工程师的价值会不会随之下降？
Lesse 认为工程师仍然能够发挥关键作用，而且现在正是深入研究这些新问题的好时机。
模型能力的提升，并不会自动解决基础设施、身份管理、安全隔离和系统监控问题。相反，当 AI 能够处理更复杂的任务、运行更长时间、调用更多工具，并与更多智能体协作时，这些问题的重要性也会随之上升。
一个能够写出正确代码的模型，不等于一个能够安全运行数周的系统。
一个能够完成单项任务的智能体，也不等于数千个智能体可以在复杂环境中可靠地协同工作。
从这个角度看，软件工程师的工作正在出现新的重心：不仅要让程序能够运行，还要让大量自主执行的智能体能够长期运行、相互协作、接受监督，并在发生异常时受到有效控制。
这并不意味着传统编程技能已经过时。恰恰相反，操作系统、网络、安全、分布式系统、运行时和基础设施等领域积累的工程经验，仍然是解决这些问题的重要基础。
当然，这也不意味着所有软件工程师都会因此受益。具体岗位和技能需求仍将发生变化，哪些技术路线最终胜出，也有待实践检验。
但至少有一点值得重视：AI 越能够自主完成复杂任务，人类就越需要构建可靠的系统，让这种能力能够安全地发挥出来。
如果未来的 AI 能够帮助人类发现新药、推动科学研究、设计新型硬件，那么除了让模型变得更聪明，我们还必须回答另一个问题：
怎样才能让成千上万个聪明的 AI 一起工作，而且不把事情搞砸？
这正是 AI 时代留给软件工程师的新问题。
编译整理自:
"The new set of problems for engineers to solve"
Katelyn Lesse, katelynlesse.com
作者现任 Anthropic 平台工程负责人，此前曾任职于 Stripe。
仅供参考和交流
