> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI代理与现有软件融合的3种方法
- URL: https://www.hubwiz.com/blog/3-ways-to-integrate-ai-agents-with-existing-softwares/
- Published: 2025-02-26T02:44:43.000Z
- Updated: 2025-02-27T09:16:36.000Z
- Description: AI代理面临着一个重要的挑战，即无缝地融入我们现有的数字生态系统，在这个系统中，它们的有效性取决于通过工具连接到天气预报、交通更新和其他服务等现实世界应用的能力。
- Author: admin
- Tags: APPLICATION, AGENT, #Import 2026-10-14 14:41

AI代理面临着一个重要的挑战，即无缝地融入我们现有的数字生态系统，在这个系统中，它们的有效性取决于通过工具连接到天气预报、交通更新和其他服务等现实世界应用的能力。

一种常见的方法是通过**API**实现这种集成，允许AI代理访问外部数据源，如天气API或交通API。然而，这种方法需要标准化接口，并且可能受限于这些API的可用性和特定性。

另一种将AI代理融入数字世界的方法是通过 **图形用户界面（GUI）**与应用程序交互，*模仿人类行为*，如点击或输入，但由于频繁的UI更改和缺乏直接的数据访问，这可能是脆弱且低效的。

第三种更稳健的解决方案涉及**在代码层面进行深度集成**，其中**AI代理**直接与应用程序的底层逻辑进行交互，提供更大的控制和精度，但需要大量的开发工作并访问应用程序的代码库。

平衡这三种方法——（1）API，（2）GUI交互，以及（3）代码级集成——提出了一个复杂的挑战，因为每种方法在可扩展性、可靠性和适应性方面都有权衡。

## 1、现状

这就是许多研究目前试图解决的问题……将**AI代理**融入我们的以人类为中心的数字世界……这提出了一个巨大的挑战，因为**AI代理的能力**与**我们现有的系统**之间存在不匹配。

**人类**依赖**直观**的图形界面和**不可预测**的工作流程，而AI代理则擅长处理**结构化**数据和**直接**访问，导致它们在如何与我们的工具互动时存在脱节。

弥合这一差距不仅需要技术上的创新——比如找到在没有完整代码访问的情况下操作的方法——还需要在软件设计上进行文化转变，以适应智能、自主的合作者。

最终，这种集成的成功取决于使AI代理足够灵活，能够在我们混乱的人类塑造的数字环境中导航，而不颠覆我们已经工作的模式。

## 2、两种最常见的方法

多模态大型语言模型（LLMs）的出现引发了对计算机界面AI代理的新一轮兴趣——这些系统能够通过自然语言理解并执行用户指令，通过与操作系统交互来实现。

*传统上*，**AI代理**通过两种主要方式与计算机进行交互：

**基于API的方法**，其中代理通过预定义的编程接口与软件通信。*使用了工具*，并且开发了代码来集成到API中。

这种方法的障碍在于它***耗时***；每个API集成都需要时间。

其次，**并非所有商业应用都提供了API**，或者公开的API功能并不包含所有的GUI功能。

随后我们看到了**基于GUI的方法**，如*Anthropic的计算机使用代理*或*OpenAI的Operator*，其中**AI代理**像人类一样导航图形用户界面。

**然而，这项研究旨在揭示第三条**，创新的途径。

API和GUI方法在准确性和效率方面都有明显的局限性，促使我们提出一种新方法：为LLM配备直接访问软件内部功能的能力——其源代码和运行时环境——以及动态生成和注入代码以供执行的能力。

有人认为这种方法可能会革新软件代理的设计，为数字生态系统铺平道路，使软件不仅能理解和执行任务，还能协作和推理以应对复杂的用户需求。

我认为现有企业可以利用这种方法；苹果公司的iOS和macOS，微软的Windows等……

![](https://www.hubwiz.com/blog/content/images/2025/02/image-446.png)

## 3、即时编译

本文介绍了一种新的软件作为代理的方法，称为即时代码生成（JiT-Codegen）。

受即时编译的启发，JiT-Codegen允许代理创建可以直接与软件的运行时上下文——如函数、数据结构和UI元素——交互的可执行代码，通过访问其源代码。

与之前关于离线软件探索或运行时交互的研究不同，JiT-Codegen开创了让大型语言模型（LLM）在其自身软件中生成和执行代码。例如，它可以使用两行代码处理需要五个GUI交互的复杂任务。

JiT-Codegen**补充**而不是**取代**基于API和GUI的代理，通过动态生成所需的函数提供灵活性，这些函数以后可以保存为API。

它还通过在代码级别工作来增强GUI操作。

![](https://www.hubwiz.com/blog/content/images/2025/02/image-447.png)

## 4、访问应用程序代码

***这是一个重要的障碍……***

JiT-Codegen方法假设了一个“白盒”设置，其中AI代理可以全面查看软件的内部——源代码、函数和运行时状态。

然而，在现实场景中，许多应用程序，尤其是专有或封闭源代码的软件，并不公开其代码。

如果没有这种访问权限，AI代理无法分析或操纵软件的内部，使得该方法在这种情况下变得不切实际。

即使在开源环境中，AI代理也需要权限和集成机制，这些可能不是随时可用或在系统间标准化的。

该研究隐含地承认了这一点，通过专注于具有代码访问能力的网络桌面应用程序的受控案例研究。

*然而，它并没有完全解决该方法如何扩展到多样化的现实世界软件生态系统的问题。*

克服这一点可能需要重新思考部署策略——也许通过沙箱环境或开发者合作——但就目前而言，受限的代码访问仍然是一个关键障碍。

![](https://www.hubwiz.com/blog/content/images/2025/02/image-448.png)

## 5、代理光谱

我最近写了很多关于代理光谱的想法。以下是关于为什么软件可能不会立即成为AI代理的一些考虑，而是引入不同程度的代理进入用户应用程序：

1. **依赖人类输入**：AI代理通常依赖于人类的提示、反馈和验证，这意味着代理受到限制——它不是完全自主的，而是被激活在用户交互的边界内。软件也可能类似地发展，代理的出现与其在应用程序中被允许采取多少主动性的程度有关。
2. **任务特定授权**：该研究中的AI代理专门用于证据合成，而不是通用决策。这反映了代理如何可能在用户应用程序中表现——情境和任务特定而非普遍适用。例如，一个写作应用程序可能会获得“代理”来重组段落，但仅在用户定义的目标范围内，而不是作为一个自由漫游的实体。
3. **协作动力学**：双向对齐模型（人类和AI共同进化他们的理解）意味着代理是共享的。软件可以将代理作为一种协作特性引入——想象成一个滑动标尺，用户可以根据需要调整他们委托的自主性程度（例如，自动填写表单与仅仅提供建议）。

## 6、综合：应用程序中的代理

*该研究间接支持的最强有力的观点是，代理很可能会以渐进的方式引入用户应用程序，而不是软件变成独立的AI代理。*

该研究中的AI并不是“成为”代理；它通过嵌入智能能力到工作流中来赋能用户。类似地，未来的软件可能会提供：

- **低代理**：被动工具（例如拼写检查）。
- **中代理**：主动建议（例如草拟电子邮件）。
- **高代理**：基于模式的上下文自动化（例如根据模式管理任务）——仍然在用户定义的护栏内。

这种光谱避免了完全独立代理的跳跃，将代理作为一种交互特性而不是固有的软件特性。

---

原文链接：[All Software As AI Agents](https://cobusgreyling.medium.com/all-software-as-ai-agents-5d3c5aa903d5?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处