2026-11-09 19:18:16 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

看懂 AI Agent：一个会自己想办法干活的数字助手，到底怎么运转

原创

取证猎人
取证猎人

Hunter取证

2026年11月6日 21:05
四川

去阅读

你可能已经在用所谓的 AI Agent 了：用 codex 写代码，它自己搜索代码库、编辑多个文件、跑测试直到通过；用豆包调研一个课题，它反复搜索、阅读，最后交出一份完整报告；用 work buddy 做网页，写文章等等

这些产品形态各异，共同点却很明确：它们不再是“你问一句、它答一句”的被动对话，而是能够自己规划步骤、调用各种工具完成任务，并根据返回结果不断调整策略的智能系统。

这篇文章讲解AI Agent 它由什么组成、三件东西怎么配合转起来、为什么光有一个聪明的模型还不够，以及最后怎么用一套朴素的框架去判断任何一个这类产品。

01先回到最朴素的问题：办成一件事，最少需要哪几样东西

不急着定义 Agent。先想一个更基本的问题：一个人要把一件事办成，最少需要哪几样东西？

一个能思考、能判断的大脑：听懂意图，决定下一步做什么。
一双能看清情况的眼睛：桌上摊着的资料、之前聊到哪一步、上一步得到了什么结果。
一双能动手办事的手脚：查资料、写文件、打电话、操作软件，把想法变成外部世界里的实际动作。

缺一样都不行：脑子再快，看不见信息只能瞎猜；眼睛再尖，手脚被绑住就只能纸上谈兵；手脚再多，脑子不清就是乱干。

把这个对照到 AI Agent，对应的正是三件东西：

大脑，是大语言模型

：整个决策内核，负责理解意图、思考规划、做出判断。
* 眼睛，是上下文

：模型在每个决策点能看到的全部信息，包括环境观察、用户记忆、领域知识、自身状态和任务进展。
* 手脚，是工具

：模型感知或改变外部世界的接口，从预定义工具调用，到动态生成代码，再到委托其他 Agent 协作、主动跟用户沟通。

一句话概括：Agent = 大模型 + 上下文 + 工具，三者缺一不可。

以后再看到一个 Agent 类产品，你可以先问三句：它靠什么想、它能看到什么、它能动什么。这三句问完，产品的骨架基本就清楚了。

图1：大脑、眼睛、手脚三件套共同构成一个能自主决策的 Agent（示意图）

02大脑：负责想清楚、做判断的那个核心

先看大脑。收到请求后，模型要先解析用户的真实意图。

用户说出口的，往往不是他真正想要的；再把模糊或复杂的任务拆成可以执行的步骤；执行过程中还要持续判断：下一步该做什么、要不要调用工具、调用哪个、传什么参数。

这种“理解—规划—执行”的能力，

来自两部分积累：

一是预训练阶段在海量文本中沉淀下来的知识与语言能力，

二是后训练阶段固化下来的决策策略。

模型还有一个值得注意的特点：它会在真正动手之前先在脑子里内部推演一步。这一步不改变外部环境，却能显著提升后续行动的质量。模型不是在做随机游走，而是在一套结构化的知识体系上展开思考。

但也要看到边界：它偶尔会编造不存在的工具或参数，会选错工具，出错后也不一定能自己拉回来。这正是后面要讨论的“模型之外那层机制”为什么存在的伏笔。

03眼睛：它能看到什么，决定了它能做出什么判断

上下文，就是每次决策时递到模型面前的全部资料。就像一个人做判断前需要看到桌上摊开的所有东西——任务说明、参考手册、之前的沟通记录、最新的数据——模型的上下文窗口，就是它的“视野”。

每次调用模型时，这些信息大致由五部分组成：

岗位说明（系统提示词）

：开发者预先写好的身份、权限和行为准则，相当于 Agent 的“岗位说明书”，整段对话中保持不变。
* 工具清单（工具定义）

：声明有哪些工具可用、各自做什么、需要什么参数。没有这份清单，模型识别不出、也调不动任何工具。
* 用户消息

：用户这一轮说了什么，也可能包含检索补充进来的外部知识。
* 模型自己之前的回复

：包括它的思考过程、给出的文字回复，以及发起的工具调用。
* 工具执行结果

：框架执行工具后返回的结果，是下一步思考最直接的依据，也让模型能从执行结果中学习，避免重复犯错。

前两项相对固定，后三项随对话不断增长。

这里有两个容易被忽略、却非常关键的事实：

没进入上下文的信息，对模型就像不存在。

再重要的背景，没递到它面前，它也无从利用。
* 没被动作接口允许的操作，模型即使想到了，也只能停留在文字建议层面。

知道怎么做，不等于有权限去做。

想体会每一部分的作用，可以用“逐个拿掉”的方式想一想：

拿掉工具清单，它无法调用任何工具；

拿掉之前的思考过程，决策前后会变得不连贯；

拿掉历史记录，它容易重复操作；

拿掉工具返回结果，它就会盲目循环。

还有一点要特别提醒：给出了回答，不等于完成了任务。一个看起来完整、语气笃定、排版工整的答案，可能只是上下文缺料时模型自行补齐的结果。判断 Agent 是否真正办成了事，不能只看它说得多漂亮。

04手脚：五类工具，让想法真正碰到外部世界

工具是 Agent 和外部世界打交道的桥梁。没有工具，Agent 只能“纸上谈兵”；有了工具，它才能真正读取或改变世界。

按与外部世界交互的方向，工具可以分成五类：

感知类

：让 Agent 获取信息。搜索引擎提供实时网络数据，文件系统读取本地文档，API 和数据库对接外部服务与核心数据。
2. 执行类

：让 Agent 改变世界。代码执行、文件操作、系统命令、外部 API 调用，把决策变成实际动作。
3. 协作类

：让 Agent 与其他角色分工合作。把专项任务委托给其他 Agent，在关键决策节点请求人类确认，或在多 Agent 体系中协同行动。
4. 事件触发类

：与前三类方向不同——它们不是 Agent 主动调用，而是作为外部输入驱动 Agent。收到一封新邮件、到了某个预定时间点、某个系统发出回调，这些事件把 Agent 唤起，让它开始后续思考和行动。
5. 用户沟通类

：Agent 主动与用户建立连接、传递信息的渠道，通过文字消息、语音通话、邮件等方式，把执行进展或主动关切传递给用户。

一次工具调用通常走四步：先在上下文里告诉模型有哪些工具可用；模型自主判断要不要用、用哪个、传什么参数；工具执行完，结果被追加回上下文；模型再基于这个结果决定下一步。这四步循环，就是下一节要讲的运行基础。

工具设计上有一条朴素原则：通用基础能力用来组合与探索，专用工具用来约束高风险和强业务规则操作。

改支付、删数据、发邮件、操作生产配置这类高风险或强业务约束的动作，应当参数明确、权限受限、全程可审计，必要时先预览再由人工确认；

底层跑代码则应放在隔离沙盒中，默认不能访问网络、不能读取授权目录以外的文件，并对运行时间、内存和输出大小设上限。

05三件套怎么转起来：想一步、做一步、看一步，循环到任务完成

三件东西齐备后，自然的问题是：它们如何配合工作？

核心运转方式是一个不断重复的循环：模型先思考当前该做什么，然后调用工具行动，再观察工具返回的结果，带着新结果继续想下一步。想一步、做一步、看一步，循环往复，直到任务完成。

Agent 一路走来的完整记录，称为轨迹：用户消息、模型回复（含思考过程和工具调用）、工具执行结果依次累积。

静态不变的岗位说明和工具清单是前缀，动态增长的历史是轨迹本身。

每次调用模型，它都能看到完整轨迹，因此清楚任务进行到哪一步、之前试过什么、得到过什么结果。

这套记录带来三个好处：便于解释和调试，用户、开发者和外部观察者都能看清它做过什么；

重复操作和错误容易被轨迹暴露；

轨迹还可以沉淀进知识库，或作为训练更好模型的经验材料。

举一个贯穿始终的例子：汇总一家公司多币种的年度收入。

第一轮：模型思考需要把欧元、英镑、日元换算成美元，于是调用汇率换算工具，分别传入对应金额。
工具返回三组换算结果，追加到轨迹里。
第二轮：模型看到结果，思考还需要汇总计算，于是调用代码解释器做总额与均值计算。
工具返回总额和季度均值。
第三轮：模型确认所有计算完成，输出最终答案。

整个过程三次迭代、四次工具调用。需

要说明的边界是：模型自主决定何时调用工具、用哪个、传什么参数；而工具本身、执行环境和返回结果，由框架或内置工具提供。

图2：思考、行动、观察首尾相接，循环推进直到任务完成（示意图）

06光有聪明大脑还不够：模型外面那层“管理机制”

到这里，Agent 的最小工作原理已经讲完：模型在循环中，借助上下文使用工具完成任务。

但前面也埋了伏笔：

模型会产生幻觉、会选错工具、遇到错误时无法自我恢复。

一个能跑通演示的 Demo，和一个能在真实业务里可靠运转的系统，中间差的正是这层机制。

这层机制围绕模型边界之内的运行与治理，做五件事：

管好上下文

：为模型提供足够充分的感知信息，让每个决策都基于完整信息判断。
* 给清工具接口

：接口定义清晰、命名直观、参数有例子、边界有说明，模型才不容易误用。
* 约束

：设定行为边界，默认采用故障安全策略——所有能力默认关闭，高风险动作必须显式开放并经过授权。
* 验证

：自动判断操作结果对不对。安全检查只看结构化数据（比如工具返回的 JSON 字段），而不看模型自由生成的文字，因为后者可能已经被提示注入操纵。
* 纠正

：发现问题时自动修正或回退；确认无法恢复之前，不把半成品结果暴露给用户，常见做法是先静默重试、接续生成，连续失败再回退到人工判断。

可以把它理解成给新来的员工配上流程管理、权限清单、审核环节和兜底预案。

行业讨论的重心，也正在从“能不能做事”转向“能不能可靠地做事”。

这套外围机制不是突然出现的，而是一层层长出来的：

最早人们只优化喂给模型的提示词；

后来意识到单纯优化提示不够，要系统管理模型能看到的所有信息；

再往后，视野扩展到模型边界内的运行与治理；

今天又进一步讨论跨轮次的持续自主运转。每一层都建立在前一层之上，是包含关系，不是替代关系。

总结行业团队在长任务 Agent 上沉淀的经验，有三条朴素原则：

保持简单

：从最简单的方案开始，确实必要时才增加复杂度。直接清晰的 API 优于复杂框架，直白代码优于聪明抽象——每多一层抽象，都会成为日后调试时的盲区。
* 保持透明

：明确展示 Agent 的执行步骤、执行日志和决策轨迹。这既是调试需要，也是用户建立信任的前提；黑箱里一旦出错，外部观察者既无法定位，也无法纠正。
* 设计好接口

：从 Agent 的视角设计接口，让它容易理解和使用，而不是只从程序员视角出发。好用、易误用的地方要在设计上就消除掉——就像 SIM 卡的缺角让卡片只能朝一个方向插进卡槽，微波炉门关不好就不会加热。

07两种办事方式：固定流程与自主规划，以及安全底线

最后看两个实际设计中绕不开的问题：步骤路径是提前定死，还是让 Agent 自己决定；以及安全护栏怎么落地。

固定流程：确定性编排。工作流通过预定义的代码路径编排模型和工具，执行路径是开发者提前设计好的：每一步做什么、下一步去哪里，由代码写死，模型只在每个节点内部负责理解和生成。比如订票流程：先核实用户身份，再搜索可用航班，完成付款，最后确认预订；节点之间的流转顺序是代码固定的，系统不会在付款前去预订座位，也不会在身份核实之前开始搜索。

它的优势是流程可控、安全性高：关键步骤不会被跳过或乱序执行，模型记错最多影响当前节点内部，无法让 Agent 跳到不该执行的分支。局限是缺乏变通：预设流程没覆盖的情况——比如付款环节用户临时想改签——固定节点路径无法灵活应对，异常只能走预设分支，或把控制权交回人工。

自主规划：动态自主决策。当固定路径满足不了需求时，就需要自主 Agent：执行路径不提前定义，而是根据环境反馈实时决定。还是订票为例，用户说“帮我订下周去上海的机票”，Agent 会自行先搜索航班、发现需要登录、先核实身份、再回来搜索；发现最便捷的航班需要转机，再主动询问用户是否接受；用户说不要转机，它再调整搜索条件。

自主性不等于无限制。自主 Agent 必须具备规划能力，能识别失败、调整策略，而不只是出错时停下；同时必须设置明确的停止条件：任务完成、调用最终输出工具、模型不再返回任何工具调用、错误次数超限、达到最大轮次，满足任一条件就退出，避免陷入死循环或过度执行。这类方式更适合开放式问题，比如修复真实代码库缺陷、操作计算机界面、需要迭代搜索和分析的研究任务；但成本和潜在错误风险也更高，部署时必须在沙盒环境充分测试，设置护栏和监控，并在关键决策点保留人工协作检查点。

实践中，两种模式往往混合使用：关键、合规要求强的流程用工作流保证可靠，需要灵活决策的部分切换到自主模式。

也有另一种混合方式：先由自主 Agent 把工作流写出来，代码一旦生成，执行阶段就退回工作流的确定性——既保留面对未知任务的灵活性，又不必让模型在每次调度上都参与决策。

安全护栏分三层。按被绕过的难度排序，越靠下越不依赖模型自己的判断，也越难被一次成功的攻击穿透：

上下文层

：管模型能看到什么，在内容进入上下文之前拦截。包括相关性分类（标记偏离主题的查询）、安全分类（检测诱导模型绕过限制的输入）、内容审核（标记不当或歧视性输入）、规则驱动的明确黑白名单与参数限制、敏感信息识别与脱敏，以及两级筛查——先用极轻量探针排查明显风险，可疑之处再交给更强的分类器复审。
2. 执行层

：管模型能做什么，在动作真正生效之前验证。核心是工具风险评级：按操作是否可逆、权限等级、财务影响，为每个工具标注低中高风险，高风险操作需要额外审查或人工确认；配合独立审查进程、最小权限凭证、沙盒隔离、人在回路和输出检查。
3. 数据层

：管最终能被改成什么样。把“谁能对哪类数据做什么”交给人类审查过的机制强制执行：数据库安全策略、约束与校验、受控视图与存储过程、运行时绑定——即使提示注入得手、生成的代码完全漏写了权限判断，越权操作仍会在数据层被拒绝。

人工干预是关键的保护措施，通常两种情况触发：一是超过失败阈值，重试次数或操作次数达到上限，就升级到人工；二是涉及敏感、不可逆或高风险操作时，先经过人工监督，至少在团队对 Agent 可靠性建立起足够信心之前如此。

还要注意：单一护栏提供不了足够保护，多个专门护栏组合起来才有韧性；护栏也会误拒合法请求，因此评估护栏时，既要测该拦的请求是否拦住，也要测明确允许的请求能否正常完成。