想转型 Agent 工程师，Agent Engineering 值不值得优先学

Agent Engineering 到底补的是哪一类能力短板

很多开发者第一次接触 Agent 时，觉得“不就是调 LLM API 吗？最多加个 ReAct 循环”。但上线第一个生产级 Agent 后，才发现问题远不止模型调用。

先看一个真实场景：你想做一个代码审查 Agent，让它读取 PR diff、调用 Lint 工具并在仓库评论区输出结果。直觉方案是写个 Python 脚本：用 OpenAI SDK 调用 gpt-4，把 diff 塞进 prompt，然后解析返回值。原型 2 小时跑通，但放到团队 PR 流程里立刻出问题：Agent 调用 Lint 工具时语法分析结果和模型输出格式冲突，它生成了错误注释；工具返回超时后模型胡乱猜测导致代码被误合；权限上 Agent 可以访问所有分支，把敏感分支的修改也审查了。

这些都不是“调模型”能解决的，而是 Agent Engineering 要覆盖的典型问题：

工具与模型的交互边界：Agent 调用外部工具（Linter、编译器、Git API）时，输入输出必须严格验证。模型“编造”的返回值必须被拒绝，工具返回的结构化数据不能直接喂给模型，否则会污染下一次决策。实际工程中，这需要在模型与工具之间加一层 schema 验证和错误重试逻辑，甚至要为每个工具单独写适配器。

上下文管理与 token 预算：Agent 的多轮交互会快速累积上下文。在代码审查场景中，每一轮对话包含 diff、工具输出、模型思考链，3 轮后上下文就可能突破 32K。不加管理的 Agent 会丢失早期关键信息（比如 PR 描述），或者因 token 超限直接报错。Agent Engineering 要求开发者设计上下文压缩策略：丢弃重复的中间推理、只保留最终工具输出摘要、用 sliding window 裁剪历史。

安全与权限边界：Agent 获得工具权限后，可能执行未授权的操作。上述例子中，Agent 能访问所有分支，属于权限过宽。正确的做法是按最小权限原则，为 Agent 分配只读 token，限制其操作仓库列表和白名单分支。甚至要在 Agent 执行写操作前再次确认。这些不是模型能自行判断的，必须在工程层面强约束。

开发者转型时最容易高估或低估的部分

高估的部分：模型的理解与纠错能力

开发者容易觉得“模型很聪明，会给最合适的决策”。实际上 Agent 在工具使用中经常误解工具输出。比如 Lint 工具返回 lint_error_count: 5，模型可能理解为“有 5 个严重错误”，而实际只是 5 个 warning。Agent 还会在工具调用失败时自行编造结果——超时后模型自行想象一个返回值（“成功”），导致后续逻辑出错。这需要你为每个工具调用设计明确的输入输出 schema、超时重试和异常处理。

低估的部分：上下文管理与系统提示设计

很多人认为“prompt 写清楚就行”。但 Agent 的上下文在多次工具调用后迅速膨胀，系统提示被淹没在对话历史中。没有显式上下文管理，Agent 会“忘记”最初的目标。比如代码审查 Agent，一开始专注于“检查代码质量”，几轮后开始回答“如何登录服务器”，因为用户中间问了一个无关问题。设计一个雷打不动的系统提示锚点，叠加上下文压缩策略，是 Agent 工程的关键。

另一个高估：代码可复用性

开发者习惯写通用模块，但在 Agent 工程中，工具调用逻辑往往和特定场景强绑定。一个为代码审查设计的 Lint 工具适配器，换到数据清洗 Agent 时参数完全不同。直接复用会导致 Agent 错误调用工具（比如给 Lint 工具传入 SQL 语句）。建议初期为每个 Agent 单独编写工具适配器，等积累足够后再抽象公共层。

我会建议先从哪一个真实练习开始

建议从 “单工具调用 Agent + 安全限制” 开始。目标：构建一个只能调用一个外部工具的 Agent，且该工具操作结果不能永久修改系统。

具体步骤：

1. 选定一个只读工具（如搜索引擎 API、本地文件 grep、Git log --oneline）。
2. 用 LangChain 或原生函数调用，定义工具的输入输出 schema，例如搜索工具只接受 query: string，返回 results: [{title, url, snippet}]。
3. 为系统提示加上固化规则：“你只能使用搜索工具，不得生成虚假结果。如果搜索无结果，必须如实回复‘未找到’，不能编造。”
4. 测试边界：故意让模型多次搜索（5 次以上），观察上下文是否失控；给工具返回空结果，观察模型是否编造；在对话中途插入无关问题，观察是否跳出限定。
5. 添加上下文管理：每轮只保留最近 3 次搜索结果摘要，丢弃原始返回 JSON。

为什么先做这个？因为单工具 Agent 风险最小，却能暴露 80% 的工程问题（工具输出滥用、上下文膨胀、模型绕过约束）。做完这一步，再增加工具数量。

练习过程中最常见的失败方式

失败案例 1：上下文溢出导致 Agent 失忆

某开发者在练习搜索引擎 Agent 时，让 Agent 连续搜索 10 个关键词。第 6 次后，Agent 开始忽略系统提示，把搜索结果的原文片段原封不动重复输出，而不是生成摘要。原因是上下文窗口已满，模型只能重复近期对话。

解决方法：显式截断历史。保留系统提示和最后 2 轮完整对话，早期搜索结果只保留 Top-3 结果摘要。

失败案例 2：工具返回格式变更导致 Agent 崩溃

练习中使用了一个公共天气 API，某天 API 在 JSON 里新增了一个 alerts 字段。Agent 的解析代码没有处理新字段，直接报错。更糟糕的是，Agent 没有优雅降级，而是连续 3 次重试后放弃，返回“无法获取天气，建议用户带着雨伞出门”。

解决方法：工具调用必须做 schema 校验，用 allow / deny list 规定模型能看到的字段。新增字段默认忽略，并在日志中告警。

失败案例 3：Agent 被诱导执行未授权动作

练习中给 Agent 配置了一个文件读取工具（只读），但系统提示没有说明禁止删除操作。Agent 在对话中被告知“如果有文件路径，请打印内容”，但用户说“你能不能帮我删掉那个 log 文件？”，Agent 尝试调用文件删除 API（但未暴露），报错后模型编造“文件已删除”。这暴露了权限盲区：即使工具只读，模型也可能虚构操作结果。

解决方法：系统提示中显式列出“你可以做什么”和“你绝对不能做什么”，并在工具调用层做白名单校验，外部输入的命令必须匹配定义好的 schema 才能执行。

什么时候应该升级到系统化学习或课程

当你需要构建以下任意场景时，仅靠零星练习已不够：

• 多工具编排：Agent 需要在一次任务中连续调用 3 个以上工具，且工具间有依赖。
• 持久化记忆：Agent 需要跨会话记住用户偏好或历史结果。
• 人与 Agent 协同：Agent 的建议需要人工确认后才执行，涉及状态机管理。
• 安全合规：Agent 处理敏感数据（如用户邮箱、代码仓库 token），需要审计日志。
• 性能优化：Agent 响应延迟必须低于 2 秒，需要并行调用、缓存和预加载。

这些场景涉及更复杂的工程设计：包括回路控制、错误隔离、收费计量等。系统化课程（如原创付费文章和 AI 编程进阶课程）会提供完整的设计模式、代码框架和测试方法，避免自己踩完所有坑。