过去一年，"Agent"几乎成为AI领域最被高估、也最被误解的概念之一。资本市场热捧其"自主决策"的未来图景，产品经理畅谈"工作流消亡论"，而开发者则在深夜的调试日志里，与无限循环的token消耗和不可复现的模型输出搏斗。这种理念层与工程层的巨大割裂，催生了大量似是而非的讨论："Agentic是未来""Workflow限制了AI能力"。然而，一旦真正进入工程落地阶段，一系列更具体、更棘手的问题便会浮出水面：
- Agent到底应该运行在本地，还是云端？
- CLI工具算不算Agent？
- Prompt约束是否等同于系统控制？
- 为什么很多"全自动Agent"最终都失败了？
这篇文章试图跳出概念争论的泥潭，从工程现实出发，系统性地梳理AI Agent正在经历的、由喧嚣走向务实的关键演进。我们不仅需要回答"Agent是什么"，更需要厘清"Agent如何被构建、部署和约束"，才能理解其真正的潜力与边界。
一、Agent不是"一个程序"，而是一种系统结构
很多人最初接触Agent，是通过AutoGPT、CLI工具或IDE插件，于是很自然地把Agent理解为："运行在本地的一段智能程序"。这个直观但片面的理解，构成了后续诸多误解的根源。
如果你观察当前主流产品形态，会发现一个明显的、分化的趋势：
- ChatGPT / Claude → 云端Agent，能力边界由API定义，安全可控，但无法触及用户私域。
- Cursor / CLI工具 → 本地增强Agent，能直接操作文件系统和开发环境，体验接近真人协作，但管理和安全是难题。
- 企业内部AI平台 → 服务端Agent + 调度系统，试图在集中管控与灵活执行间找到平衡。
这说明一件事：Agent不是一个单体程序，而是一个"分布式结构"。其核心在于智能与执行的分离。一个更准确的抽象是：
- 云端：负责认知（理解、推理、决策）。这是模型的天然主场，拥有最强的算力和最新的知识。
- 本地：负责执行（文件、系统、浏览器）。这是与环境交互的入口，拥有用户身份、上下文和操作权限。
- 中间层：负责调度（工具调用、状态管理、安全策略）。这是工程的集中体现，负责将"思考"转化为安全、有序的"行动"。
换句话说，Agent更像"一个系统"，而不是"一个工具"。将Agent视为单一程序，就如同将"操作系统"视为"CPU"一样，忽略了其作为复杂系统的本质。
二、两条路线的本质差异：云Agent vs 本地Agent
当前Agent落地，本质上是两种架构路线在并行发展，它们源于对"智能"和"控制"的不同取舍。
1）云端 Agent：集中式智能
典型流程是：用户请求 → 服务端Agent → 调用工具 → 返回结果（可能流式）。
这种模式的核心优势在于"可控"：
- 统一权限控制：可以在云端精细化管理用户对数据、API的访问权限。
- 成本可限制：通过token配额、调用次数、超时机制，有效控制运营成本。
- 审计与合规：所有交互日志集中存储，便于审计、回溯和模型迭代。
- 模型快速迭代：无需用户端更新，即可升级模型能力。
但它的天然限制也很明显：它无法进入用户的"真实环境"。例如：
- 无法访问本地私密文件。
- 无法复用浏览器中的用户登录态。
- 无法直接操作操作系统或GUI界面。
这使得云端Agent在处理需要"深度介入"的任务时显得力不从心。
2）本地 Agent：环境嵌入式智能
CLI和IDE Agent代表了另一种方向：Agent直接运行在用户环境中。这类Agent的体验非常接近"真人协作"，可以：
- 修改本地代码、创建文件。
- 执行shell命令、运行脚本。
- 调用git进行版本管理。
- 直接使用浏览器或系统已保存的登录态，完成复杂UI操作。
然而，问题也同样突出：
- 难以集中管理：每个用户的本地环境都是独特的"雪花"，部署、更新和监控困难。
- 安全风险更高：本地Agent拥有用户级权限，一旦被恶意利用，后果严重。用户需要高度信任其行为。
- 企业难以规模化部署：合规、安全、审计等要求，使得企业难以将本地Agent作为标准工具推广。
关键结论是 ：未来不会是二选一，而是分层协作："云端负责思考，本地负责执行"。云端提供智能决策和全局策略，本地提供环境感知和执行能力，中间层负责安全、高效的调度。
三、CLI Agent的真实角色：半个Agent Runtime
很多人会说："CLI就是本地执行器"，但这个说法其实低估了它的作用。一个典型的CLI Agent（如集成在终端中的AI助手）内部，往往已经构建了一个精简但完整的Agent运行时（Runtime）：
- Prompt构造逻辑：动态组织系统指令、历史对话和当前上下文。
- Tool选择机制 ：根据用户意图和当前状态，决定调用哪个工具（如
read_file,run_command）。 - 多轮推理循环（agent loop）：在"观察-思考-行动"的循环中持续迭代，直到任务完成或达到终止条件。
- Memory管理：维护短期会话记忆，并可能引入长期记忆（如向量数据库）。
- 上下文压缩策略：当对话历史过长时，自动进行摘要或裁剪，以避免超出模型上下文窗口。
举个具体例子：用户输入："帮我找出这个项目的性能瓶颈"。CLI可能执行如下过程：
1）规划 ：模型判断需要先了解项目结构，于是调用list_files工具。
2）执行 ：CLI执行ls -R或类似命令，获取文件树。
3）分析 ：将文件树返回给模型，模型分析后指出，需要查看主要的Python文件或package.json中的脚本。
4）执行 ：CLI调用read_file读取目标文件。
5）推理 ：模型发现可疑的同步数据库调用或未优化的循环。
6）验证 ：模型决定运行性能测试，CLI执行pytest --bench或time python script.py。
7）综合：模型将代码分析和测试结果结合，生成最终报告。
在这个过程中：
- 模型只负责"局部推理"------理解当前子任务、选择下一步工具、分析单次返回的数据。
- CLI负责"整体调度"------维护任务状态、管理工具执行、处理异常、控制循环。
这意味着：当前CLI Agent，本质是"工程在主导，模型在辅助 "。或者说，是弱Agent + 强工程。CLI框架用工程化的方式，将模型这个强大的"大脑"嵌入到一个稳定、可控的执行框架中。
四、Agentic vs Workflow：不是对立，而是分层
很多讨论把Agentic和Workflow对立起来：
- Workflow → 固定流程 → 不智能、僵化。
- Agentic → 自主决策 → 更高级、更智能。
但在实际工程中，这种非黑即白的对立是站不住脚的。我们看两个极端情况：
1）纯Workflow系统
例如：Step1 → 查表 → Step2 → 聚合 → Step3 → 输出。它的优点是稳定、可预测、成本固定。但问题是，一旦输入稍有变化（比如查询的字段名变了，或者需要的数据来源不同了），这个流程就立即失效，需要人工介入修改代码。
2）纯Agent系统
完全放开，让模型自己决定：做几步、查哪些数据、是否继续探索。它的优点是灵活，能应对未知情况。但问题也同样致命：
- 不稳定：每次执行路径都可能不同，结果难以复现，调试困难。
- 成本不可控：模型可能陷入死循环，或在无意义的探索上消耗大量token。
- 难以调试：没有固定路径，出了问题你不知道是模型"想错了"，还是工具"用错了"。
因此，真正可落地的方案是：Agentic内核 + Workflow外壳。也就是：
- Agent负责"路径选择"：在流程的关键节点，由模型根据当前上下文决定下一步该怎么做。这赋予了系统灵活性。
- 系统负责"边界控制"：用工程化的Workflow来定义Agent活动的"轨道"。例如，规定最大步骤数、定义清晰的工具接口、设置安全拦截器、在关键节点强制进行状态检查。
这就像在围棋棋盘上落子：模型决定在哪落子（Agentic），但棋盘和规则（Workflow）限制了落子的方式和范围，保证了游戏的持续性和可评判性。
五、Prompt约束的局限：为什么limit.md不够
很多工程会设计类似soul.md（角色）、tools.md（工具定义）、limit.md（行为限制）的文档来约束Agent。例如在limit.md中写："SQL查询必须加LIMIT 1000"。
这确实是一种控制，但问题在于：它无法被强制执行。这是一种"软控制"，依赖模型的"自觉"。在复杂场景下，模型很可能：
- 遗忘：在多轮推理中，上下文过长导致模型遗忘了早期的约束指令。
- 被干扰 ：用户提供的示例或对话历史中的其他信息，可能覆盖了
limit.md的优先级。 - 出错：模型在生成SQL时可能产生语法错误，导致"LIMIT 1000"被放在了错误的位置。
- 被绕过 ：模型可能通过其他方式（如
SELECT *）间接实现全表扫描，而并未触发显式的LIMIT。
如果没有系统层拦截，这条危险的SQL仍然会被执行，可能导致数据库过载或资源滥用。
因此，必须严格区分两种控制：
1）软控制（Prompt）：
- 作用：引导模型行为，提高正确率。
- 方式：通过系统指令、少样本示例、思维链提示等。
- 局限性：不保证执行，易被上下文干扰。
2）硬控制（System）：
- 作用：强制执行，保证安全和稳定。
- 方式：例如：
- 自动改写SQL：在工具调用层，拦截并改写生成的SQL，强制添加
LIMIT。 - 检测全表扫描：在执行前，用语法分析器检测是否存在危险操作，并阻止或告警。
- 限制最大step数：在agent loop中，超过步数则强制终止。
- 超时终止：为每个工具调用或整个任务设置超时时间。
- 权限沙箱：将Agent的执行限制在特定目录或容器内。
- 自动改写SQL：在工具调用层，拦截并改写生成的SQL，强制添加
一个成熟系统一定是"两层控制叠加"。Prompt负责告诉Agent"应该怎么做"，而System负责确保Agent"必须怎么做"。
六、为什么"本地执行"是不可绕过的
有一类任务，天然无法通过API完成，例如："用我的账号登录公司内部系统，提交一份报销单"。
这个任务的问题不在技术难度，而在"边界"：
- 身份在本地：关键的认证信息（如cookie、SSO token）存在于本地浏览器，无法通过API传递。
- 系统在内网：目标系统可能没有对外暴露的API，仅可通过内网访问。
- 操作是UI交互：需要模拟人机交互：打开页面、等待加载、点击按钮、填写表单、处理弹窗、点击提交。
它的执行过程是：打开页面 → 登录 → 导航到报销页面 → 点击"新建报销" → 填表 → 上传附件 → 提交。
这类任务的本质是 "操作环境"，而不是"调用接口"。它要求Agent必须像人一样，理解界面、模拟输入、处理异步响应。
因此，一个真正通用的Agent，必须具备"进入环境执行"的能力。无论这个环境是CLI、IDE、浏览器还是操作系统，Agent都需要一个能够感知并作用于该环境的"执行臂"。本地执行，是Agent从"数字助理"走向"数字操作员"的必经之路。
七、Agent的三层结构：未来标准模型
为了统一这些分散的能力，我们可以将Agent的架构抽象为清晰的三层模型：
1）认知层（云端或边缘）
- 功能：理解用户意图、将复杂任务分解为子任务（规划）、根据执行反馈动态调整策略。
- 承载：大语言模型（LLM）是核心，负责"思考"。它不关心具体如何点击一个按钮，只关心"需要点击那个按钮"。
- 特点：重计算、可集中部署、易于迭代。
2）工具层（抽象接口）
- 功能 ：为认知层提供统一的、标准化的工具接口。这些工具是对底层能力的抽象，例如
search_file、click_element、execute_sql。 - 承载：由工程代码实现，负责将模型的"意图"翻译成具体的、可执行的指令。
- 特点：起到"翻译官"和"断路器"的作用。安全策略、权限控制、成本审计在此层实现。
3）执行层（本地/环境）
- 功能：真正与物理或虚拟环境交互。执行具体的操作，如文件读写、系统命令调用、鼠标键盘模拟。
- 承载：运行在用户本地设备或特定服务器上，拥有该环境的"操作权"。
- 特点：重操作、环境敏感、需要高度的安全隔离。
一个典型流程会变成：用户请求 → 云端Agent规划 → 调用工具层接口 → 工具层进行安全校验 → 将任务派发给本地执行器 → 本地执行器完成操作并返回结果 → 认知层分析结果，决定下一步。
八、从"调用API"到"操作世界"
传统Agent依赖的核心技术是 function calling，即"输入 → 调函数 → 返回结果"。这在API丰富的世界（如CRM、数据库）里非常高效。
但现实世界的大量系统，没有API，只有界面。它们可能是几十年前的遗留系统，可能是仅限内网访问的管理后台，也可能是设计精美的SaaS应用。要自动化这些系统，就必须让Agent学会操作GUI。
于是出现了新方向：GUI Agent / Computer Use。例如：
- 识别屏幕：通过计算机视觉或解析可访问性树，理解当前界面的构成。
- 找到目标：定位到"提交"按钮或"用户名"输入框。
- 执行操作：模拟鼠标点击、键盘输入。
对比：
- API方式 ：调用
create_order(data)，一步完成，稳定、快速。 - GUI方式：打开网页 → 等待加载 → 识别"下单"按钮 → 点击 → 等待表单加载 → 识别表单字段 → 输入数据 → 识别"提交"按钮 → 点击 → 等待确认信息。过程漫长、脆弱。
后者的意义在于：它极大提升了泛化能力。只要是人能操作的界面，GUI Agent理论上就能操作，无需等待开发者提供API。这对于自动化长尾任务和遗留系统具有颠覆性意义。
但代价也显而易见：
- 更慢：每一步都可能涉及等待和视觉识别。
- 更不稳定：界面的一丝变化（按钮颜色、位置微调）就可能导致任务失败。
- 更难控制：难以精确预测其下一步行为，调试困难。
这恰恰印证了前文的观点：越是靠近"操作世界"，越需要强大的工程来兜底。
九、当前阶段的本质：工程在兜底Agent
现在很多Agent系统的真实状态是：
- 看起来是Agent在决策，充满智能感。
- 实际上是工程在限制它，为它保驾护航。
让我们审视一下：tool schema是你精确定义的，限制了模型可以调用的函数和参数；step数是你硬性限制的，防止它无限循环；是否继续执行，是你在代码里写逻辑判断，而非完全交给模型决定。模型只是在你的规则框架内，做有限的选择。
这说明了一个核心事实：当前阶段，Agent本身还不够可靠，必须依赖强大的工程约束来确保其行为的安全、可控和有效。我们不是在构建一个"全知全能的AI"，而是在用工程学的方法，将一个大模型"驯化"成一个能在特定领域、按特定规则工作的可靠工具。
十、未来趋势：Agent Runtime的独立
一个重要趋势正在形成：Agent的运行时（runtime）正在从具体的应用（如CLI工具、IDE插件）中抽离出来，成为一个独立的、标准化的基础设施层。
现在，每个Agent框架都各写一套：
- Cursor有自己的runtime。
- 各种开源CLI Agent有自己的loop实现。
- 企业内部平台也在自研。
这种重复造轮子的状态，低效且阻碍了生态发展。未来，我们很可能看到标准化的Agent Runtime出现。它负责：
- 工具调度：标准化的工具注册、发现和调用机制。
- 权限控制：统一的、细粒度的权限模型，用户可为不同Agent授予不同权限。
- 状态管理：管理会话状态、长期记忆、执行快照。
- 执行回放：记录Agent的每一步决策和行动，用于调试、审计和复盘。
- 多Agent协作：提供原生支持，让不同专长的Agent可以安全、高效地协同工作。
你可以把它理解为 "Agent操作系统"。就像操作系统为应用提供了统一的文件、网络、进程管理接口一样，Agent Runtime将为上层应用（各种Agent）提供统一的认知、记忆、工具和协作能力。
十一、一个更现实的结论
如果用一句话总结当前阶段：Agent不是"自动完成任务"，而是"在约束下完成任务"。
这意味着：
- 不能完全放权给模型：完全放权等于放弃控制，结果将是不可预测和不可管理的。
- 也不能完全写死流程：完全写死等于放弃智能，无法应对现实世界的复杂性和变化。
真正的关键在于，找到"自主性 "和"可控性"的平衡点。这个平衡点不是静态的，它会随着模型能力的提升、工程技术的成熟以及具体应用场景的变化而动态调整。在安全性要求极高的金融系统，我们可能更倾向于Workflow；在探索性的代码生成任务中，我们可能给予Agent更多自主权。
结语
AI Agent的发展，并不是从"工具"到"智能"的简单升级，而是一次深刻的系统架构的重构。它正在经历三个关键变化：
- 从单体程序 → 分布式系统：将认知与执行分离，构建云-端协同的复杂系统。
- 从API调用 → 环境操作：从调用接口的"绅士"，变为能操作界面的"实干家"。
- 从工程主导 → 模型主导（但仍受约束）：模型的决策权在增加，但始终被包裹在工程搭建的坚实框架内。
未来的Agent，不只是"会回答问题"，而是：
"能够在真实环境中，安全、可控地完成复杂任务的执行体"
我们现在，正处在这个体系逐渐成型的激动人心的阶段。它要求我们同时具备模型理解力、系统设计力和工程落地力。这既是挑战，也是构建下一代智能应用的根本机遇。