学 AI Agent 前,我发现最该先听懂的是这 10 个词

很多人说自己在学 AI，其实学的是工具使用。

我一开始也是这样。会用 ChatGPT，能写 prompt，能让 AI 帮我改代码、整理文档、生成方案，就觉得自己已经开始理解 AI 了。但越往后学，我越明显地发现，真正让我卡住的不是工具怎么用，而是一些基础概念之间的关系，我其实没有完全想明白。

比如 LLM 到底是不是一个更聪明的聊天机器人？Prompt 是不是写得越长越好？Agent 和 workflow 的区别在哪里？工具调用为什么会成为 AI Agent 的核心能力？如果 AI 接入钱包、签名、链上操作，它的权限边界又应该怎么设计？

这些问题如果只从 AI 角度看，可能会有点抽象。但从 Web3 开发者的视角看，它们会突然变得很具体。因为 Web3 系统里有钱包、有签名、有资产、有权限、有链上记录。AI 一旦从“回答问题”走向“帮用户执行操作”，它就不再只是聊天窗口，而可能成为系统流程里的执行者。

所以我现在越来越觉得，学 AI Agent 之前，最该先听懂的不是某一个很酷的框架，而是一些底层概念。它们会决定我们后面怎么看 Agent、workflow、AI Coding、链上自动化，以及 AI × Web3 的系统设计。

01｜LLM 很强，但它不是天然可信的事实来源

LLM，也就是大语言模型，本质上是一个根据上下文生成文本的模型。更通俗一点说，它像一个读过大量资料、很擅长理解语境和组织语言的助手。你给它一个问题，它会结合当前上下文，生成一个看起来合理的回答。

但这里有一个很重要的边界：LLM 不是数据库，也不是区块链浏览器，更不是天然可信的事实来源。它擅长理解、总结、推理和生成，但不代表它一定掌握实时事实，也不代表它能直接验证链上状态。

这点对 Web3 特别重要。比如你问它“这个钱包地址安全吗”，如果它没有接入链上数据工具，它只能根据你提供的信息做分析，不能真的知道这个地址最近有没有恶意交易、有没有被标记、有没有和钓鱼合约交互过。

所以我现在不会把 LLM 的回答直接当作事实本身。更准确的理解是：LLM 很适合处理语言和逻辑，但涉及资产、交易、合约权限、链上状态时，它必须接入可靠的数据源或工具，才能把回答变成可验证的结论。

02｜Prompt 不是咒语，而是任务接口

刚开始学 prompt 的时候，很多人会把它理解成“怎么把一句话写得更神奇”。我现在更愿意把 prompt 看成一种任务接口。它是在用自然语言定义输入、目标、约束、判断标准和输出格式。

这其实和写函数很像。你不能只说“帮我分析这个合约”，因为这个任务太模糊了。更好的方式是告诉 AI：请从权限控制、重入风险、签名验证、资金流向、状态更新顺序这几个角度分析这个 Solidity 合约，并输出风险等级、问题位置和修改建议。

这样一来，AI 才知道它要看什么，不要泛泛而谈；它要按什么标准判断；最后应该交付什么结果。好的 prompt 不是越长越好，而是边界清楚、任务明确、上下文够用。

在 AI × Web3 场景里，prompt 更像自然语言版本的接口文档。尤其涉及钱包、签名、交易、私钥、安全建议时，prompt 必须明确哪些事情 AI 可以做，哪些事情不能做。

比如 AI 可以解释签名含义，但不应该诱导用户签名。AI 可以生成交易草稿，但真正发起交易前必须让用户确认。AI 可以读取链上记录，但不能凭空判断一个项目一定安全。

03｜很多时候不是 AI 不会，而是你没让它看见上下文

Context window 可以理解成模型一次对话中能够处理的上下文范围。它像 AI 当前的工作台，能放下你前面说过的话、贴过的代码、给过的文档，以及当前正在问的问题。

但这个工作台不是无限大的。如果你一次性塞进去太多内容，模型可能抓不到重点；如果你给的信息太少，它又只能靠猜。很多时候，AI 不是不会解决问题，而是它根本没有看到足够的信息。

我以前排查钱包连接问题时，也会直接把报错丢给 AI，让它帮我看哪里错了。后来发现，如果我不把 chain 配置、provider 配置、依赖版本、调用组件和错误日志一起给它，它给出的建议基本只能停留在通用层面。

在 Web3 开发里，一个问题通常不只在某一行代码里。钱包连接失败，可能和 Reown 配置有关；合约调用失败，可能是 ABI、链 ID、合约地址、权限、gas、签名、参数编码中任意一个环节出了问题。

所以我现在用 AI Coding 时，会更习惯把项目背景、当前目标、相关文件、错误日志、已经尝试过的方法，以及不希望它改动的部分一起提供给 AI。这比单纯说“帮我修 bug”有效很多。

04｜Workflow 不是让 AI 多做几步，而是把任务变成稳定流程

如果说 prompt 是单次任务的指令，那么 workflow 更像一条稳定的流水线。它由一组明确步骤组成，用来反复完成某一类任务，而不是每次都靠临场发挥。

比如写一篇技术文章，也可以设计成一个 workflow：先确认主题，再明确读者，再列核心概念，再补真实场景，再写初稿，再检查技术准确性，最后调整成适合某平台阅读的表达。

这会比直接对 AI 说“帮我写一篇文章”稳定得多。因为每一步都有自己的目标，也能在中间发现问题，而不是最后才发现整篇文章方向跑偏。

Web3 场景里的 workflow 更直观。一次链上操作可能包括连接钱包、检查网络、读取余额、构造交易、请求用户签名、发送交易、等待 receipt、更新前端状态、记录交易哈希。

这些步骤不是随机发生的，而是有顺序、有状态、有失败处理的。AI workflow 也是一样，重要的不是“让 AI 多做几步”，而是每一步的输入、输出和异常处理要清楚。

如果一个 workflow 里的某一步失败了，系统应该知道是重试、暂停、让用户确认，还是直接终止。这也是我觉得 AI × Web3 很有意思的地方：链上世界天然强调流程、状态和可验证结果，而 AI workflow 也需要这些东西来变得可靠。

05｜Agent 不是更会聊天，而是能围绕目标行动

很多人听到 Agent，会以为它就是更智能的 ChatGPT。但我觉得这个理解还是太轻了。普通聊天模型更多是在回答问题，而 Agent 更接近围绕一个目标，拆解任务、调用工具、根据结果继续行动的系统。

比如你说“帮我分析这个钱包最近有没有风险”。普通 AI 可能会告诉你应该查看交易记录、授权记录和交互合约。但一个真正的 Agent，可能会调用链上数据工具，读取最近交易，检查授权列表，识别高风险合约，最后生成一份风险报告。

这就是“回答”和“执行”的差别。Agent 的关键不只是会说，而是能把目标拆成步骤，并且在过程中根据工具返回结果继续判断下一步。

但在 Web3 里，Agent 的边界会格外敏感。因为它一旦接入钱包和交易能力，就可能从建议者变成执行者。涉及资产和权限时，自动化不是越多越好，而是要分层设计。

读取链上数据可以自动化，生成风险分析可以自动化，构造交易可以半自动化。但真正签名和发送交易，必须让用户明确确认。一个好的 Web3 Agent，不应该只是帮用户点按钮，而应该让每一步都可解释、可确认、可追踪。

06｜AI 想真正做事，必须先接上可靠工具

LLM 自己不会真的查链上数据，也不会真的跑代码、查余额、读合约状态。它需要工具。工具可以是搜索引擎、数据库、区块链 RPC、钱包 SDK，也可以是一个后端接口。

这就是 tool use 的意义：让 AI 不只停留在语言层面，而是能连接外部系统，获得真实数据，并在一定规则下完成任务。

比如一个 AI 钱包助手，如果没有工具，它只能解释什么是 approve。但如果它接入了链上工具，就可以帮你查你授权了哪些合约、授权额度是多少、最近有没有可疑交互、某个合约是否有风险特征、是否需要取消授权。

不过，接入工具不代表结果一定准确。工具只是提供能力，不代表系统一定可靠。如果工具数据源不可信，或者 AI 错误理解了工具返回结果，仍然会出错。

所以 tool use 的重点不是“能调用”，而是调用什么工具、什么时候调用、如何校验结果、失败时怎么处理，以及哪些步骤必须回到用户确认。这也是为什么 AI Agent 的难点不只在模型，而在工程系统设计。

07｜AI Coding 不是替你写代码，而是参与工程协作

我以前也会把 AI Coding 简单理解成“让 AI 帮我写代码”。但现在我觉得这个理解太窄了。真正有价值的 AI Coding，不是让 AI 一次性生成一大坨代码，而是让它参与完整的开发流程。

比如帮我读懂一个陌生模块，帮我梳理某个 hook 的数据流，帮我根据现有项目风格补一个组件，帮我检查类型是否严谨，帮我判断合约有没有权限漏洞，帮我把 PRD 拆成可执行任务，或者帮我写测试用例覆盖边界情况。

对 Solidity 和 React 项目来说，AI Coding 最有用的地方往往不是从零生成，而是在已有项目中按规则修改。因为真实项目里最难的不是写出一段能跑的代码，而是让它符合当前架构、类型约束、业务逻辑和安全边界。

这里也有一个很容易踩的坑：完全相信 AI 生成的代码。尤其是合约代码，不能因为它看起来很像 OpenZeppelin 风格就直接用。权限、签名、nonce、防重放、资金流向、边界条件，都需要人工 review。

我现在更倾向于把 AI 当成一个很强的 junior teammate。它可以很快给我草稿、思路和检查方向，但最终判断必须由开发者自己负责。

08｜Guardrails 不是限制能力，而是定义系统边界

如果说 Agent 代表能力，那么 guardrails 代表边界。AI 系统越能做事，越需要清晰的边界。否则它越强，风险也越大。

比如一个 Web3 AI 助手，可以帮用户分析交易，但不能直接替用户签名；可以提醒风险，但不能保证某个项目“绝对安全”；可以构造交易参数，但必须展示给用户确认；可以调用工具，但不能偷偷读取用户没有授权的数据。

这不是限制 AI 发挥，而是让系统变得可上线、可使用、可被信任。尤其在钱包、资产、身份、权限相关场景里，guardrails 不是锦上添花，而是系统设计的一部分。

一个 AI 钱包助手至少应该遵守这些边界：不接触私钥，不自动签名，不隐藏交易风险，不默认扩大授权额度，不把模拟结果当成最终成功，不替用户做不可逆资产操作。

这些规则看起来保守，但它们决定了系统是否值得被信任。AI Agent 如果要进入真实产品，能力和边界必须一起设计，而不是先把功能做出来，出问题后再补安全规则。

09｜没有 Tracing 的 Agent，本质上还是黑箱

普通聊天里，我们可能只关心最后答案。但 Agent 系统里，只看最后答案远远不够。因为你需要知道它为什么做这个判断，调用了哪些工具，工具返回了什么，中间有没有失败，有没有误解用户意图，有没有越权调用。

这就是 tracing 的价值。它记录 AI 系统每一步做了什么、为什么做、调用了什么工具、得到什么结果，让整个执行过程可以被复盘。

在 Web3 场景里，这个概念更关键。链上交易本身是可追踪的，但 AI 的推理过程和工具调用如果没有记录，就会变成黑箱。

比如一个 AI Agent 帮用户完成一次自动化操作，最后交易失败了。你不能只告诉用户“失败了”，而是要知道失败发生在哪一步：是钱包未连接，网络不对，签名过期，nonce 错误，合约 revert，还是 RPC 节点返回异常。

所以 tracing 不只是方便 debug，它也是信任机制的一部分。如果我们真的想做可信的 AI × Web3 系统，就不能只记录最终结果，而要记录关键过程。

10｜Human-in-the-loop 是关键节点的人类确认

做自动化的时候，很多人会觉得最好完全不需要人参与。但在高风险场景里，人类确认不是落后，也不是低效，而是必要的系统设计。

AI 可以帮用户分析一笔交易，比如调用的合约是什么，转出的资产是什么，授权额度是多少，是否涉及无限授权，是否存在高风险函数，模拟执行结果如何。但最后是否签名，应该由用户决定。

这就是 human-in-the-loop。它指的是在 AI 系统流程中，保留人的判断、确认或干预。尤其在 Web3 里，这个机制非常自然，因为钱包签名本身就是一个人类确认节点。

我不太相信“只要 AI 足够聪明，就可以把人完全拿掉”。至少在资产、权限和身份相关场景里，好的系统不是让人消失，而是让人在关键地方出现。

AI 负责处理复杂信息，工具负责获取真实数据，workflow 负责组织流程，guardrails 负责限制边界，human-in-the-loop 负责关键决策。它们组合起来，才更接近一个可靠的 Agent 系统。

如果把这 10 个概念拆开看，它们好像都是 AI 入门词汇：LLM、prompt、context window、workflow、agent、tool use、AI coding、guardrails、tracing、human-in-the-loop。

但如果把它们放到 AI × Web3 的场景里，它们会组成一套完整的系统语言。Prompt 定义任务，context 提供信息，workflow 拆解流程，agent 判断下一步，tool use 获取真实数据，guardrails 限制越权，tracing 记录过程，human-in-the-loop 保留关键确认。

最后

我是 yoona，区块链技术专业出身，一名正在系统学习 AI 的开发者。我想把自己学到的知识，尽量放回真实项目和开发场景里去理解。接下来，我会继续记录自己学习 AI 的过程，也会分享我对 Web3 技术、AI 工具和 Agent 系统设计的一些观察和理解。

欢迎大家一起交流学习呀～