工程师实战——AI Agent 的底层逻辑与实战落地

weixin_42314775

17人浏览 · 2026-07-02 11:21:05

weixin_42314775 · 2026-07-02 11:21:05 发布

一、先说清楚：你以为的 Agent 和真正的 Agent

我是薛定谔的悦，一名大厂储能算法工程师。

最近这段时间，“AI Agent"这个词已经泛滥到了某种程度。朋友圈里、技术论坛上、各种产品发布会的PPT里，这个词满天飞。但你要是认真问一圈，大多数人说不出个所以然来——顶多是"哦，就是那种能自己做事的 AI嘛”。

这个回答没错，但太粗了。

作为储能领域的工程师，近一年来一直接触AI，同时也研究把AI Agent引入工作流程中，我见过太多人把概念搞混。有人把带了个搜索插件的 ChatGPT 叫 Agent，有人把自动回复邮件的脚本叫Agent，也有人把真正能自主规划、执行、反馈的系统叫 Agent。这三个东西，底层差了不止一个量级。

所以我想从工程师的角度，给你捋清楚几件事：

第一，Agent 不是一个非此即彼的概念，它是一条连续的谱系，不同系统落在这条谱系的不同位置。

第二，从普通问答到真正的自动化Agent，中间差的那层东西，跟模型本身没太大关系，关键在模型外面怎么搭。

第三，搭一个能用的 Agent 并不难，工具链现在已经很成熟了，一个下午就能跑起来一个能用的东西。

先把这个框架立住，后面说的所有东西都往这个框架里装。

二、谱系这件事：从聊天到全自动，差在哪里

我们做系统设计的时候，有个习惯——遇到复杂问题先画边界，把它拆成一个坐标轴，搞清楚各个点分别意味着什么。Agent这个问题也一样。

最左端：纯问答模式

你打开任何一个大模型的对话框，输入一个问题，模型吐出一个答案，交互结束。这是最基础的使用方式。

它的特征很明显：单轮或多轮对话，但每次只有输入输出，模型的影响范围不超出这个对话窗口。它不会去改一个文件、不会调一个接口、也不会在你关掉窗口之后继续做任何事。

这类场景很多，很多日常的使用确实就停留在这一层，完全够用。

往右走一步：配了工具的对话

这是现在很多产品所处的位置。模型在给你回答的过程中，会自己决定去调某些工具——搜一下网页、读一个文件、查一条数据库记录，然后把结果整合进回答里。

注意这里的关键词：模型自己决定。不是你告诉它"先搜索再回答"，而是它在推理过程中判断需要用工具，然后调了。这个自主决策的能力，是向 Agent 迈出的第一步。

典型例子：你问一个配了 Web Search 工具的模型"今天特斯拉股价多少"，它自己去搜，然后告诉你结果。你没有分步骤指挥它，它自己知道该怎么做。

再往右：多步骤自动工作流

这一层开始进入我认为真正有意思的区域了。

你给模型一个高层目标，它自己把这个目标拆解成子任务，按顺序或者并行地执行，中间根据每一步的结果调整后续计划，最后给你一个成品。

举个例子：你告诉它"帮我整理一份本周AI 行业的重要动态，格式是摘要加分析，输出到一个 markdown文件里"。它会自己去搜索相关新闻、筛选、提炼重点、组织结构、写内容，最后存文件。你全程没有做任何中间步骤的决策。

这和上一层的本质区别是：任务不是一步就完成的，中间有多个环节，而且环节之间有依赖关系，需要根据上一步的结果决定下一步怎么做。

最右端：全自动、持续运行的 Agent

这才是严格意义上的 Agent。

特征是：不需要人在循环里。你部署好之后，它按照自己的计划定时运行，监控外部输入，处理事件，调用服务，完成任务。你设定一次目标，然后它自己跑，你只需要定期看结果、做策略层面的调整。

这类系统从工程角度看，已经接近一个普通的后台服务了，只不过决策核心换成了大模型。

三、构成 Agent 的三要素

抛开各种营销话术，从工程实现的角度来说，一个 Agent区别于普通聊天的核心就是三件事。这三件事你加得越多，自动化程度就越高，你需要亲自介入的部分就越少。

要素一：工具调用能力（Tool Use）

这是 Agent 能对外部世界产生影响的基础。

没有工具调用，模型就是一个"嘴上说"的系统——它能告诉你答案，但它自己做不了任何改变。加上工具之后，模型就能真正执行操作：往数据库写数据、发一封邮件、调用第三方 API、在本地创建或修改文件、运行一段代码等等。

从实现角度看，工具调用的机制并不复杂。你定义一批工具，每个工具有名称、描述和参数规格。模型在推理时，如果判断需要某个工具，就生成一个结构化的调用请求，你的应用层解析这个请求，实际执行对应的操作，把结果回传给模型，模型基于结果继续推理。

这个循环是 Agent 能力的底层基础设施。

要素二：持久记忆（Memory）

上下文窗口是模型的"工作内存"——对话窗口里的内容它都能"看到"，但一旦超出窗口限制或者会话结束，这些信息就没了。

真正的 Agent 需要比这更持久的记忆机制。通常有几种做法：

会话级记忆：在同一个会话内维护对话历史，让模型能引用前面说过的事。
跨会话持久化：把重要信息存到文件或数据库，下次启动时加载回来。
语义检索记忆：把历史信息向量化存起来，需要的时候用语义搜索找相关内容注入上下文，适合信息量很大的场景。

记忆机制的质量，直接影响 Agent 在长任务中的表现。没有好的记忆管理，Agent 会"失忆"——忘掉最初的目标、做过的决策、你设定的约束。

要素三：执行循环（Agentic Loop）

普通的问答是一次性的：你输入，模型输出，结束。

Agent 是循环的：目标输入 → 规划 → 执行步骤 → 观察结果 → 调整计划 → 继续执行 → 直到目标达成。

这个循环是 Agent 能完成复杂任务的关键。它让系统能够处理失败——某一步出错了，可以重试或者换一个方法；它让系统能够处理不确定性——不需要在开始时就把每一步都规划好，可以根据实际情况动态调整。

这三个要素，缺了哪一个，你的系统就只能算"接近 Agent"而不是"真正的 Agent"。

四、Agent 能干什么：几种典型落地形态

理论讲完了，来看实际能落地的场景。以下这几类，我觉得是当前阶段最有实用价值的。

研究型 Agent：

场景：你有一个需要大量信息收集和整理的任务——调研某个技术方向、整理竞品分析、写一份行业报告。

传统做法：你自己去搜索引擎一个个查，读文章、做笔记、整理成结构化的文档，可能要花半天甚至更长。

Agent 做法：你描述清楚要研究的问题，Agent自动拆解成几个核心子问题，分别搜索，评估来源质量，提取有效信息，汇总成结构化报告。整个过程几分钟到十几分钟。

关键点：你得在system prompt里告诉它什么叫"高质量来源"、输出格式是什么、对不确定的事情要怎么处理。这些指令越清晰，结果质量越稳定。

写作型 Agent：

场景：你需要持续产出内容，但不想每次都从零开始。

核心价值不是让AI “替你写”，而是让 AI 按照你定义的风格和规范来写，你只需要做最后的审核和调整。

实现方式：把你的写作风格、用词偏好、内容结构、目标读者全都写进 system prompt，作为固定的约束。这样每次的输出都在你的风格框架内，减少大量来回修改的成本。

代码型 Agent：

这是目前落地最成熟的场景，也是整个行业里工具链最完善的方向。

Claude Code、GitHub Copilot Workspace、Cursor 这些工具，本质上都在做同一件事：让模型不只是"给代码建议"，而是能直接操作文件系统、运行代码、读取报错、根据报错修改代码、再运行、再验证，形成完整的开发闭环。

对个人开发者来说，用这类工具来搭建自己的小工具、自动化脚本、内部系统，效率提升是实实在在的。

业务流程Agent：

适合处理那些重复性高、规则清晰、但量大到人工处理很费时间的任务——客户邮件分类回复、数据报表生成、合同文本提取关键信息等等。

这类场景的重点是把业务规则翻译成清晰的 prompt，然后验证边界情况的处理是否符合预期。

五、实战：零代码搭一个 Telegram Agent

说了这么多理论，来做点实际的。我们用 Claude Code 搭一个跑在服务器上的 Telegram 机器人，它用Claude当大脑，具备基本的对话能力和持久记忆。

你不需要会写代码。整个流程需要的技能：能打字、能看懂终端输出、能在Telegram 里操作。

环境准备

你需要三样东西：

Claude API 密钥

去 console.anthropic.com 注册开发者账号，申请 API Key。注意这是按token 用量计费的，不是包月的那种。对个人机器人来说，日常聊天量的话每月开销大概在几美元以内，具体取决于你选哪个模型和使用频率。

Telegram Bot Token

在 Telegram 里搜索 BotFather，这是 Telegram 官方的机器人管理工具。跟它发送/newbot，按提示操作，几分钟就能拿到一个 BotToken。

一台Linux VPS

跑一个 Telegram 机器人对服务器配置要求极低，1 核 CPU、1GB内存就够了。DigitalOcean、Hetzner、Vultr 都有基础套餐，一个月4-6 美元。国内的话阿里云轻量应用服务器也行。

服务器拿到之后，SSH 进去，装 Claude Code：

npm i -g @anthropic-ai/claude-code

模型选择

在开始之前，先决定好用哪个模型，这影响成本和能力上限。

Haiku 4.5：最便宜，响应快，适合任务简单、对话量大的场景。
Sonnet 4.6：性价比最高的选择，能力足够处理绝大多数个人用途，推荐大多数人用这个。
Opus 4.7：能力最强，成本最高，只在需要做复杂分析、处理长文档、答案质量要求很高的时候才值得用。

个人机器人日常用途，Sonnet 4.6 完全够用。

第一步：让机器人跑起来

进入服务器终端，启动 Claude Code，把下面这段描述贴进去：

  Build me a Telegram bot that uses the Claude API as its brain.

  Requirements:
  - Language: Python
  - Library for Telegram: python-telegram-bot
  - Claude model: claude-sonnet-4-6
  - The bot receives a message, sends it to Claude API, and returns Claude's response to Telegram
  - Maintain conversation history per user — each user has their own context within the session
  - Add a /start command that introduces the bot
  - Add a /clear command that resets conversation history for that user

  Create all necessary files: main bot file, requirements.txt, and a .env file template for API keys.
  Do not hardcode any API keys — read them from environment variables.

这段prompt 在做的事是：告诉 Claude Code 用 Python 写一个 Telegram 机器人，每个用户有独立的对话上下文，有/start 和/clear 两个命令，API 密钥从环境变量读取而不是写死在代码里（这是安全实践的基本要求）。

Claude Code 会生成代码、创建 requirements.txt、生成 .env 模板文件。你把你的实际 API 密钥填进 .env文件，然后按它给你的指令运行就行了。

第二步：做成系统服务

机器人代码能跑起来了，但现在是手动在终端里运行的。你关掉 SSH 连接，机器人就停了。

需要把它配置成 systemd 服务，让它在后台持续运行，服务器重启后自动启动，崩了自动重启：

  Create a systemd service file so this bot runs automatically on my Linux VPS and restarts if it crashes.

  The service should:
  - Start automatically when the server boots
  - Restart automatically if it crashes
  - Load environment variables from the .env file in the project folder
  - Save logs to a file I can check later

  Also write me the exact terminal commands to install the service, start it, check if it is running, and view the logs.

执行完这步之后，你的机器人就是一个常驻的后台进程了，跟 nginx 这类服务没有本质区别。

第三步：加上持久记忆

现在有个问题：机器人重启之后，之前所有用户的对话历史全丢了。对于一个助理类的机器人，这体验很差。

修复方法是把对话历史持久化到文件：

  The bot loses conversation history when it restarts. Fix this.

  Save each user's conversation history to a JSON file on disk after every message. Load it back automatically when the bot starts.

  Add a maximum history length — keep only the last 20 messages per user so the context window never gets too long.

这里有个细节要注意：为什么要设最大历史长度？因为模型的上下文窗口有token上限，历史消息不加限制地积累，最终会超出限制；同时历史越长，每次请求的 token 消耗也越多，成本线性增长。保留最近 20条是个合理的折中——既保留了足够的上下文，又控制了成本。

六、扩展功能：一步步让你的 Agent 更强

基础框架搭好了，接下来可以按需往上加能力。每加一个功能，就是写一段新的prompt丢给 Claude Code，让它把功能实现进来。

联网搜索

给 Agent 加上实时信息获取的能力。当用户问的是需要最新信息的问题时（股价、新闻、最近发生的事），Agent自动判断是否需要联网搜索，而不是只靠训练数据里的知识来回答：

  Add web search capability to the bot using the Tavily API.

  When the user asks something that requires current information — news, prices, recent events — the bot automatically searches the web and includes the results in its response.

  The bot should decide on its own when to search and when to answer from memory. Add TAVILY_API_KEY to the .env file template.

  Use Claude's tool use feature to implement this cleanly.

Tavily 是专门为 LLM 集成优化的搜索 API，比直接用通用搜索 API 的效果要好，而且有免费额度够个人用途用。

笔记存储

让 Agent 能记住你说过的重要信息——想法、任务、研究结论，随时可以调取：

  Add a note-saving feature to the bot.

  When the user says "save this", "remember this", or "note:", the bot saves the content to a notes.txt file with a timestamp.

  Add a /notes command that returns the last 10 saved notes.
  Add a /clearnotes command that deletes all saved notes.

这个功能简单但实用，尤其是把机器人当成随身助理用的场景。

访问控制

默认情况下，任何人只要知道你机器人的用户名就能发消息给它，消耗你的 API 额度。如果这个机器人是私人用的，加一个用户 ID白名单是有必要的：

  Add user restriction to the bot so only I can use it.

  Add my Telegram user ID to the .env file as ALLOWED_USER_ID.If anyone else messages the bot, it responds with "This bot is private." and ignores all further messages from that user.

  Also add how I can find my own Telegram user ID — either through the bot itself or another method.

这不是什么复杂的安全机制，就是最基本的访问控制——不加这个，你的机器人就是一个向全世界开放的免费 AI服务，由你的账户付费。

费用追踪

Claude API 按 token 计费，长期用着用着你可能不知道花了多少钱。加个简单的费用追踪：

  Add basic cost tracking to the bot.

  After each Claude API response, log the number of input tokens and output tokens used.Keep a running total in a costs.json file.

  Add a /costs command that shows: total tokens used today, total tokens used all time, and an estimated cost in USD based on claude-sonnet-4-6 pricing.

这个功能对控制成本意识很有帮助。当你能看到具体的 token 消耗，你会自然而然地开始优化 prompt 的长度。

定时主动推送

让 Agent 主动给你发消息，不是被动等你问：

  Add a scheduled daily briefing to the bot.

  Every day at 8:00am, the bot sends me a message with:
  1. A motivational one-liner (short, not cheesy)
  2. A reminder to check my top priority for the day
  3. One random useful fact about productivity or AI

  Send it to my Telegram user ID from the .env file.
  Use the schedule or APScheduler library to implement this.

这个功能把机器人从被动响应模式推进了一步——有了主动触发，它开始更像一个真正的助理了。

七、日常维护：几个你肯定会用到的操作

机器人部署起来之后，有几个操作你迟早会用到。

修改 Agent 的系统人格

打开机器人的主Python 文件，找到文件顶部定义 system prompt的那个变量，直接改文本内容，保存文件，然后：

  sudo systemctl restart<你的服务名>

重启完成后，新的人格立即生效。不需要改任何其他代码。

检查机器人运行状态

  sudo systemctl status <你的服务名>

看到 active (running) 就是正常运行中。看到 failed 就去查日志。

查日志

  journalctl -u <你的服务名> -n 50

看最近 50 行日志。出问题的时候，错误信息都在这里，找到具体的报错信息，拿去问Claude Code 怎么修。

新增功能

进到项目目录，启动 Claude Code，直接描述你想要的功能，它会读你现有的代码，在不破坏已有功能的前提下把新功能加进去，然后告诉你是否需要重启服务。

八、最难搞的问题：上下文管理

如果你真的把Agent 用起来，做一些持续时间长、步骤多的任务，你一定会遇到这个问题：Agent 开始"忘事儿"了。

具体表现是：任务做到一半，它忘了最开始的目标；或者做完一轮，下次打开新会话，之前做的进展全没了，从头开始；又或者任务跑
着跑着，它开始重复已经做过的步骤。

这不是模型变傻了，是上下文管理没做好。理解它发生的原因，才能有针对性地解决。

原因一：上下文窗口溢出

所有大模型的上下文窗口都有 token 上限。当对话历史超过这个上限时，模型会截掉最早的内容——而最早的内容往往是最重要的：你
设定的任务目标、约束条件、已经做出的关键决策。

这些东西丢了，模型的行为就开始漂移。

解法：让 Agent 定期做上下文压缩。每隔 10-15
条消息，主动让它把到目前为止的进展、关键决策、剩余任务压缩成一段摘要，用这段摘要代替原来的长历史继续运行：

  The conversation is getting long. Compress everything important into a summary:

  1. Original goal
  2. What has been done and what was found
  3. Key decisions made
  4. What still needs to happen

  After writing the summary, continue from there. Treat this summary as the new starting point.

原因二：会话中断

关掉浏览器、SSH 断线、重启服务——任何中断都会导致会话历史清空。下次打开，Agent 从零开始，不知道之前做到哪里了。

解法：在任务的关键节点，主动让 Agent 生成一份检查点笔记，存到文件里：

  Before we continue, write a brief checkpoint:
  1. What have you completed so far?
  2. What are the key decisions or findings from this session?
  3. What still needs to be done?
  4. What context would you need to continue this task in a new session?

  Keep it under 200 words.

下次打开新会话时，把这个检查点贴进去，Agent 就能从中断的地方继续，而不是重来。

完整的记忆文件格式：

  After completing each major step, write a memory note in this format:

  STEP COMPLETED: [what was done]
  KEY DECISIONS: [choices made and why]
  CURRENT STATE: [where the task stands now]
  NEXT STEP: [what should happen next]

  This note will be used to resume the task in a new session without losing context.

原因三：任务中途被打断

Agent 不知道中断之前执行到哪一步了，下次恢复时可能会重复执行已经完成的步骤，或者跳过某个步骤。

解法：任务开始前就把恢复机制设计好，而不是出问题了再补救。用下面这个 prompt 恢复中断的任务：

  We are resuming a task from a previous session. Here is the context:

  [paste your memory note here]

  Based on this:
  1. Confirm your understanding of where we are
  2. Identify the next step
  3. Ask any questions needed to continue

  Do not repeat work that has already been completed.

原因四：关键信息没有固化

有些信息是全程都需要的——你对任务的定义、对输出格式的要求、不能做某些事情的约束。这些放在对话历史里，随着对话变长会被截
掉。

解法：把这类信息直接写进 system prompt。System prompt
在每次请求时都会被包含在上下文里，不受对话历史截断的影响，是最稳定的"工作记忆"。