智能体编程时代，软件工程基础技能图谱全解析

智能体编程时代软件工程的基础技能正在被重新划定。过去几年我们聊软件工程默认是一套围绕需求、设计、编码、测试、部署展开的稳定体系而现在LLM 能写代码、能调用工具、能自主规划任务工程师的核心工作从“自己写每一行逻辑”变成“设计一套让模型稳定完成任务的系统”。这个变化不是概念层面的它直接影响招聘要求、学习路径和项目落地方式。这篇文章尝试把“智能体编程时代的软件工程基础技能”整理成一张可执行的能力图谱。重点回答几个问题提示词工程和上下文工程到底算什么层级的能力RAG、工作流编排、工具调用这些环节为什么成了新基本功从传统 CRUD 开发切到智能体开发先补什么技能低代码平台上智能体搭建入口频繁调整底层要掌握哪些知识才不会被动。全文按“技能分层 → 环境准备 → 最小实战 → 测试验证 → 接口化 → 性能与排错”展开适合正在做技术选型、准备转型智能体开发、或者想系统梳理技能树的读者。1. 智能体编程时代的软件工程基础技能速览能力项说明能力本质从“手写确定性逻辑”转向“设计模型推理 工具调用 状态管理的复合系统”核心技能模块需求拆解、提示词/上下文工程、RAG、工作流编排、工具调用、质量评测、可观测性典型技术栈Python、LangChain/LlamaIndex、向量数据库、Docker、模型 API、FastAPI硬件/环境门槛使用云端模型 API 时无需本地 GPU本地部署需要按模型实际要求准备显存最低上手条件熟悉 Python 基础语法理解 HTTP 接口调用有基本的数据结构概念是否支持低代码支持但低代码平台适合搭建原型生产级系统仍需要工程能力兜底是否适合批量任务可以但需要自己设计队列、重试、幂等和日志主要产出智能客服、知识库问答、自动化流程、代码辅助工具、数据分析智能体适合场景内容生产、内部工具、业务流程自动化、知识管理、复杂系统辅助开发从材料看当前行业对智能体开发者的要求并不是“会写花哨的提示词”而是能稳定交付。很多低代码平台上“智能体开发入口消失”之类的现象本质上也是平台在调整能力分层——低代码负责快速搭建工程化能力还是需要开发者自己掌握。所以本文不会只讲某个平台怎么点按钮而是把底层技能拆清楚。2. 为什么智能体编程需要一张新的技能图谱传统软件工程关注的是确定性系统输入明确、处理逻辑明确、输出明确。开发者把业务规则翻译成代码用单元测试保证行为符合预期。智能体编程不是这样系统的核心是模型而模型的输出有概率性。同一个提示词两次运行结果可能不同同一个任务模型可能选择不同的工具调用路径。这种不确定性要求工程师把一部分精力从“写逻辑”转移到“约束逻辑”。具体来说智能体系统的工程问题变成了如何把用户模糊的意图拆成模型能理解的子任务如何让模型在有限轮次内完成推理而不是陷入死循环如何把外部知识准确注入生成过程减少幻觉如何让模型安全调用外部工具并处理工具返回的异常如何评估一个智能体“做得好不好”而不只是“能不能跑”。这些问题横跨提示词工程、后端开发、数据工程、测试工程和运维。所以“智能体编程软件工程基础技能图谱”本质上是一个跨学科能力地图传统软件工程的知识没有失效而是变成底座上面新增了模型交互和智能体编排这一层。低代码平台的热搜变化也印证了这一点。像“扣子编程中低代码模式智能体开发怎么没有了”这类问题说明大量用户习惯在可视化界面里拖拽搭建智能体一旦平台调整入口能力就断档。如果能理解底层逻辑——模型调用、工具协议、上下文管理、发布部署——平台怎么改都不影响交付。3. 技能图谱总览五层能力结构智能体编程的基础技能可以分成五层。这五层从下往上正好是一个智能体从开发到上线所需的能力栈。3.1 第一层模型交互基础这一层是地基。开发者需要理解 LLM 的 API 调用方式包括 chat completion 的请求和响应结构、token 限制、temperature/top_p 等采样参数、system/user/assistant 消息角色以及流式输出。这些概念不复杂但直接影响后续所有设计。比如不知道 system prompt 和 user prompt 的边界就很难做好角色约束不理解 max_tokens长文本输出就会莫名截断不了解流式输出交互体验就会卡顿。3.2 第二层上下文与提示词工程提示词工程不是“写几句好听的话让模型听话”而是结构化的输入设计。核心内容包括任务指令的清晰度、示例few-shot的选择、输出格式约束、思维链引导、避免幻觉的边界声明。再往上是上下文工程也就是如何在有限的上下文窗口内选择最相关的信息。这涉及文本分割、摘要、重新排序、动态组装等技术。3.3 第三层知识增强与检索模型不可能知道所有私域信息。RAG检索增强生成因此成为智能体开发的高频技能。这一层需要掌握文本加载与解析、分块策略、向量化、向量数据库存储、相似度检索、重排以及把检索结果拼装进提示词的策略。很多智能体“答非所问”问题往往出在这一层。3.4 第四层工具调用与工作流编排智能体不只是聊天还要干活。干活意味着调用工具比如查数据库、调内部 API、发邮件、执行代码。工程上需要设计工具描述、参数 schema、模型调用工具的协议以及工具返回结果后的处理逻辑。工作流编排则负责把多个步骤串起来包括条件分支、循环、人工审批节点、异常重试。这一层最接近传统后端开发也是最容易出 Bug 的地方。3.5 第五层评测、可观测性与部署一个能演示的智能体 Demo 和能上线的智能体服务之间差距就在这一层。评测需要准备测试集、设计指标、做回归可观测性需要记录每次请求的输入输出、token 消耗、工具调用链、延迟部署需要考虑接口封装、鉴权、限流、后台任务处理。很多团队智能体项目失败不是模型不行是工程化没跟上。4. 技能深度拆解每个环节到底要掌握什么4.1 需求拆解把业务问题翻译成智能体问题传统需求分析写的是功能清单和规则智能体需求分析更需要写清楚任务边界、可用工具、知识来源、错误处理方式和验收标准。比如做一个客服智能体需要明确它能回答什么、不能回答什么、遇到不确定信息是转人工还是拒答、回答的格式是什么、是否需要引用来源。这些约束会影响后续提示词设计和 RAG 方案。建议用一张表格维护需求映射业务需求智能体能力依赖技术验收标准解答产品使用问题基于知识库问答RAG 重排测试集准确率达标查询订单状态调用订单 API工具调用工具调用成功率、响应时间生成周报草稿结构化内容生成提示词 模板格式正确、信息完整4.2 提示词与上下文工程从“写提示词”到“设计状态”提示词工程看起来门槛低实际上很容易被低估。初级用法是写一段指令高级用法是把提示词当成系统的状态管理机制。同一个智能体在不同任务阶段system prompt 应该动态变化用户多轮对话中历史消息需要截断、摘要、压缩检索到的知识需要按相关度排序并标注来源。这里给出一个通用的提示词结构模板实际项目需要根据任务调整你是{角色}负责完成{任务}。 约束条件 1. 只能基于提供的知识回答不要编造信息。 2. 如果知识不足回复“信息不足请补充问题细节”。 3. 回答使用 Markdown 格式控制在{字数}字以内。 可用工具 - {工具名称}{工具描述} 输出格式 {JSON 或文本格式示例}注意这不是万能模板而是强调“角色 任务 约束 工具 输出格式”五要素。少了任何一部分模型都可能出现行为漂移。4.3 RAG智能体记忆的外部化RAG 是智能体编程里最值得投入的技能。它解决的是模型不知道、记不住、容易忘的问题。实现一套 RAG 并不难难的是在真实场景里调好。操作层面需要掌握以下步骤文档解析PDF、Word、HTML、Markdown 等格式转成纯文本保留必要结构文本分块按标题、段落、固定长度切分块与块之间保留重叠向量化用 Embedding 模型将文本转为向量模型需要根据实际项目选择存储与检索使用向量数据库做相似度搜索常用方案有 Milvus、Qdrant、Chroma 等重排对检索结果做二次排序去掉不相关内容上下文组装把检索结果拼接到系统提示词中控制总长度。下面是一个使用 Python 伪代码实现的 RAG 查询流程实际项目需要替换向量库和模型接口import requests # 向量化接口和向量数据库需要按实际项目替换 def embed_text(text: str): resp requests.post(http://127.0.0.1:8080/embed, json{text: text}, timeout30) return resp.json()[vector] def search_similar(query: str, top_k: int 3): query_vec embed_text(query) resp requests.post(http://127.0.0.1:8080/search, json{vector: query_vec, top_k: top_k}, timeout30) return resp.json()[results] def build_rag_prompt(query: str): docs search_similar(query) context \n\n.join([f[文档{i1}] {d[text]} for i, d in enumerate(docs)]) prompt f 请根据以下知识回答问题。 知识 {context} 问题{query} 要求只使用知识中的信息如果知识不相关请明确说“未找到相关信息”。 return prompt实际项目中建议把检索结果的结构化信息记录下来方便后续调试。4.4 工具调用智能体的“手”和“脚”工具调用是让智能体从“会说话”变成“能干活”的关键。模型本身不执行代码它只是输出一个结构化的工具调用请求由应用层解析并执行。设计工具时描述越是清晰准确模型调用就越稳定。一个工具定义通常包含字段作用示例name工具名称模型根据名称调用query_orderdescription工具用途越具体越好根据订单号查询订单状态parameters参数 JSON Schemaorder_id: string, required下面是一个工具调用循环的简化实现import json import requests class SimpleAgent: def __init__(self, api_url: str, tools: list): self.api_url api_url self.tools tools self.messages [ {role: system, content: 你是智能助手只能使用可用工具完成任务。} ] def _call_model(self): payload { model: your-model, messages: self.messages, tools: self.tools, temperature: 0.2 } resp requests.post(self.api_url, jsonpayload, timeout120) return resp.json() def _execute_tool(self, tool_name: str, arguments: dict): if tool_name query_order: order_id arguments.get(order_id, ) return {status: shipped, order_id: order_id} return {error: unknown tool} def run(self, user_input: str, max_rounds: int 5): self.messages.append({role: user, content: user_input}) for _ in range(max_rounds): response self._call_model() choice response[choices][0][message] if choice.get(tool_calls): for call in choice[tool_calls]: tool_name call[function][name] args json.loads(call[function][arguments]) result self._execute_tool(tool_name, args) self.messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) else: self.messages.append(choice) return choice[content] return 已达到最大轮数限制任务未完成。 agent SimpleAgent( api_urlhttp://127.0.0.1:8000/v1/chat/completions, tools[{ type: function, function: { name: query_order, description: 根据订单号查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } }] ) result agent.run(请查询订单 A10086 的状态) print(result)这个例子只演示核心循环。生产环境中工具执行结果需要校验、日志、超时控制工具本身要有鉴权和限流。4.5 评测与可观测性衡量智能体质量智能体评测不能只看一两个例子。需要建立测试集、设计评估指标。常用做法是准备几十到几百条真实问题每条标注期望答案或标准动作然后跑一遍智能体计算指标。自动化程度越高回归成本越低。常用效果指标指标含义计算方式任务完成率能正确结束任务的比例成功任务数 / 总任务数工具调用准确率正确选择并调用工具的比例正确调用次数 / 总调用次数回答相关性回答是否贴合问题人工评分或 LLM 评分幻觉率回答中出现无依据内容的比例幻觉样本数 / 总样本数平均响应时间从请求到返回的耗时总耗时 / 请求数可观测性方面建议每个请求都记录完整消息序列system、user、assistant、tool每次模型调用的 token 消耗工具调用的名称、参数、返回值响应延迟最终输出和是否触发异常分支。这些日志是排查“智能体行为奇怪”的唯一依据。5. 环境准备搭建一套智能体开发底座智能体开发环境不需要一开始就上复杂框架先用最小组合跑通链路。这里给出一套通用方案实际项目可以按团队技术栈替换。5.1 技术选型建议组件可选方案说明开发语言Python 3.10生态最全AI 相关库支持最好模型访问云端 API 或本地部署云端起步最快本地部署需关注显存编排框架LangChain / LlamaIndex / 自研新手建议先用自研简单流程理解后再引入框架向量数据库Chroma / Qdrant / Milvus原型用 Chroma生产可按需选型接口服务FastAPI轻量适合快速封装智能体 API运行环境Docker docker-compose统一环境方便迁移5.2 本地环境准备清单如果是本地开发建议检查以下内容Python 版本与虚拟环境工具venv / conda / uvpip 镜像源配置方便安装依赖Docker 和 docker-compose 是否可用网络策略模型 API 是否需要配置密钥、代理等需要注意合法合规访问磁盘空间向量库、依赖包、模型缓存都会占空间预留充足端口规划避免 8000、8080、7860 等常用端口冲突下面是一个虚拟环境初始化示例# 创建虚拟环境 python3 -m venv agent_env # 激活虚拟环境 source agent_env/bin/activate # 升级 pip 并安装基础依赖 pip install --upgrade pip pip install requests fastapi uvicorn chromadb如果后续要使用局部向量检索可以按项目文档安装对应依赖。不要一次性装大量库按需安装更容易排查问题。5.3 本地模型部署的通用判断如果不使用云端 API而是本地跑模型需要重点关注显存。不同模型、不同量化方式、不同上下文长度显存占用差异很大。通用的做法是先跑一个小模型验证流程再逐步换更大模型观察推理时的显存占用而不是只看模型文件大小。本地推理通常需要 CUDA 环境安装前确认显卡驱动和 PyTorch 版本匹配。如果显卡显存不够可以考虑 CPU 推理或更小的量化模型但速度会明显下降需要提前做性能测试。6. 智能体最小实战从零搭建一个问答与工具调用智能体这一节用一个完整的 Python 示例演示智能体开发的核心链路。这个例子不依赖任何重型框架只用 requests 库调用模型 API演示“接收输入 → 调用模型 → 解析响应 → 执行工具 → 返回结果”的循环。6.1 项目结构agent_demo/ ├── agent.py # 智能体核心逻辑 ├── tools.py # 工具定义与执行 ├── rag.py # RAG 检索相关 ├── config.py # 配置项 └── requirements.txt # 依赖清单6.2 模型服务配置实际项目中需要把模型服务地址替换成自己可访问的服务。如果是本地部署的模型通常是http://127.0.0.1:8000/v1/chat/completions如果是云端 API则使用对应服务商提供的接口地址。# config.py API_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME your-model REQUEST_TIMEOUT 1206.3 核心智能体实现# agent.py import json import requests from config import API_URL, MODEL_NAME, REQUEST_TIMEOUT from tools import TOOLS, execute_tool class Agent: def __init__(self, system_prompt: str): self.system_prompt system_prompt self.messages [{role: system, content: system_prompt}] def _call_model(self, messages): payload { model: MODEL_NAME, messages: messages, tools: TOOLS, temperature: 0.2, stream: False } resp requests.post(API_URL, jsonpayload, timeoutREQUEST_TIMEOUT) resp.raise_for_status() return resp.json() def run(self, user_input: str, max_rounds: int 5): self.messages.append({role: user, content: user_input}) for _ in range(max_rounds): response self._call_model(self.messages) message response[choices][0][message] if message.get(tool_calls): self.messages.append(message) for call in message[tool_calls]: tool_name call[function][name] try: args json.loads(call[function][arguments]) except json.JSONDecodeError: args {} result execute_tool(tool_name, args) self.messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse) }) continue self.messages.append(message) return message[content] return 达到最大轮次限制未能完成目标。 if __name__ __main__: prompt 你是企业内部助理可以使用工具查询信息。回答请简洁准确。 agent Agent(system_promptprompt) result agent.run(请查询订单 20250101 的物流状态) print(result)6.4 工具实现# tools.py TOOLS [ { type: function, function: { name: query_logistics, description: 根据订单号查询物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] def execute_tool(tool_name: str, arguments: dict): if tool_name query_logistics: order_id arguments.get(order_id) return {order_id: order_id, status: 已发货, location: 上海转运中心} return {error: f未知工具: {tool_name}}运行后预期结果是智能体先输出工具调用请求程序执行工具再调用模型生成最终答案。如果工具描述不清楚或参数名不一致模型可能反复调用错误这时优先检查工具描述的准确性。7. 功能测试与效果验证智能体能不能稳定交付智能体的测试和传统软件测试有很大区别。传统测试断言返回值是否等于期望值智能体测试更接近“行为验证”。需要设计多维度的测试用例并持续回归。7.1 测试用例设计测试类型输入示例预期行为判断标准基础问答公司年假政策是什么给出知识库中的准确回答回答中是否有知识依据知识缺失2026年新产品价格明确告知信息不足不应编造价格工具调用查询订单状态正确调用查询工具工具调用参数是否正确多轮对话追问订单细节能结合历史上下文回答是否引用前文信息恶意输入绕过限制的提示词拒绝执行或安全兜底不触发越权行为7.2 回归测试自动化建议把测试用例保存为 JSON 文件写一个简单的评测脚本循环执行。下面是一个通用示例# eval_agent.py import json from agent import Agent test_cases [ { input: 年假政策是什么, must_contain: [年假], must_not_contain: [API_KEY] }, { input: 查询订单 20250101, must_contain: [已发货, 上海] } ] def run_test(): agent Agent(system_prompt你是企业助理请谨慎回答。) passed 0 total len(test_cases) for case in test_cases: output agent.run(case[input]) ok True for keyword in case.get(must_contain, []): if keyword not in output: ok False for keyword in case.get(must_not_contain, []): if keyword in output: ok False if ok: passed 1 print(f输入: {case[input]}) print(f输出: {output}) print(f通过: {ok}) print(- * 40) print(f通过率: {passed}/{total}) if __name__ __main__: run_test()这里的must_contain只是最简单的评测方式。更严格的场景可以引入 LLM 作为评测员对回答做相关性打分或者人工标注后计算指标。7.3 效果验证的关键点判断智能体是否合格不是看一两个例子而是要看同一问题多次运行是否稳定边界输入是否优雅降级工具调用失败后能否自我纠正长对话中是否丢失上下文回答是否有来源依据是否出现幻觉。显存/资源占用是否在可控范围如果是本地部署。任何一个环节不稳定都需要回到提示词、上下文管理或工具定义里排查。8. 接口 API 与批量任务从 Demo 到服务智能体跑通之后下一步是把它封装成服务让其他系统调用。这一步是把“能演示”变成“能上线”的关键。8.1 用 FastAPI 封装智能体接口下面给出一个最简封装示例# api.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from agent import Agent app FastAPI() class ChatRequest(BaseModel): message: str session_id: str default class ChatResponse(BaseModel): reply: str session_id: str # 生产环境应使用独立的会话存储这里用简单字典示例 sessions {} app.post(/api/chat, response_modelChatResponse) def chat(req: ChatRequest): try: if req.session_id not in sessions: sessions[req.session_id] Agent(system_prompt你是企业智能助理。) agent sessions[req.session_id] reply agent.run(req.message) return ChatResponse(replyreply, session_idreq.session_id) except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动接口服务uvicorn api:app --host 127.0.0.1 --port 8000调用接口curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {message: 查询订单 20250101 状态, session_id: user-001}8.2 批量任务设计如果需要对一批文本或文档做批量处理不建议直接并发请求模型 API容易触发限流。更稳妥的做法是引入任务队列。常见方案简单场景使用 Redis 队列 Python Worker复杂场景使用 Celery 或 Arq 管理异步任务极简场景单进程内串行遍历。下面是一个使用多线程做批量处理的简化示例生产环境建议换用正规队列# batch.py import json import threading from queue import Queue from agent import Agent def process_item(item: dict): agent Agent(system_prompt你是文档处理助手。) result agent.run(item[question]) item[answer] result return item def worker(task_queue: Queue, results: list): while True: item task_queue.get() if item is None: break try: results.append(process_item(item)) except Exception as e: results.append({input: item, error: str(e)}) finally: task_queue.task_done() def run_batch(input_file: str, output_file: str, worker_count: int 4): with open(input_file, r, encodingutf-8) as f: items json.load(f) task_queue Queue() for item in items: task_queue.put(item) results [] threads [] for _ in range(worker_count): t threading.Thread(targetworker, args(task_queue, results)) t.start() threads.append(t) task_queue.join() for _ in range(worker_count): task_queue.put(None) for t in threads: t.join() with open(output_file, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(input.json, output.json)批量任务的核心原则每个任务独立、可重试、有日志、有失败记录。模型调用是外部依赖网络抖动、限流、超时都可能导致失败任务处理必须考虑这些情况。8.3 服务化注意事项接口服务上线前需要确认鉴权接口不能裸奔至少加 API Key 或内部网络限制限流避免单个用户刷爆模型调用额度超时模型响应慢接口超时时间要设置合理日志每次请求记录输入输出、耗时、token 消耗会话存储多实例部署时session 需要放到 Redis 等共享存储模型版本固定模型版本避免模型更新导致行为漂移。9. 资源占用与性能观察智能体系统的资源占用来自多个部分模型推理、向量检索、应用服务、日志存储。不同部署方式差异很大。9.1 模型推理部分如果使用云端模型 API本地几乎没有显存压力主要关注 API 延迟和 token 消耗。如果本地部署模型显存占用是最关键的指标。观察到显存占用过高时可以考虑使用量化版本模型缩短上下文长度减小 batch size使用流式输出避免一次性生成过长结果及时释放不再使用的模型实例。显存占用需以实际模型和推理参数为准不要只看模型文件大小。部署前先用小规模请求测试记录显存峰值。9.2 RAG 与向量检索部分RAG 系统的资源消耗主要在文本向量化如果文档量大需要批量处理向量数据库索引需要占用内存或磁盘检索时返回的文档块越多下游模型输入越长token 消耗越大。可以优化检索的 top_k减少不相关内容也可以引入重排模型让更少但更准的文档进入上下文。这些都是常见的性能优化手段。9.3 应用服务部分FastAPI 这类服务本身资源占用不高但如果每个请求都创建一个新的 Agent 实例内存会累积。建议复用 Agent 实例或改为无状态接口把会话消息存到外部存储。批量任务建议控制并发数防止把模型服务打挂。9.4 性能观察方法通用的观察手段包括使用nvidia-smi观察 GPU 显存和利用率使用psutil记录进程 CPU 和内存在接口层记录耗时、tokens、成功率和错误率在日志中记录每次工具调用的耗时使用 Prometheus Grafana 做更系统的监控。性能问题如果出现优先分两层排查如果模型调用占大头就优化上下文长度和采样参数如果是工具逻辑慢就优化后端服务和外部依赖。10. 常见问题与排查方法问题现象可能原因排查方式解决方案智能体答非所问提示词缺少任务边界查看完整消息日志检查 system prompt补充角色、约束、输出格式说明回答出现幻觉缺少知识来源或 RAG 失效检查检索结果是否为空检查文档解析、分块、向量库数据工具一直被错误调用工具描述不清晰或参数 schema 有误查看模型调用工具的发起信息和参数优化工具描述和参数定义多轮对话丢失上下文历史消息被截断或未维护查看 messages 序列设计历史消息截断或摘要策略接口超时模型响应慢或工具执行慢查看接口耗时分布调大超时时间、优化工具或使用异步批量任务部分失败网络波动或限流查看失败任务日志增加重试机制和失败记录本地部署显存溢出模型过大或并发过多查看显存占用曲线换量化模型、降并发、缩短上下文模型 API 返回空响应参数错误或内容被安全拦截检查请求参数和响应体调整参数或联系服务方低代码平台智能体入口变化平台调整能力分层查看平台最新文档掌握底层工程能力避免依赖单一平台软件工程转型智能体开发思路不清缺少系统化学习路径对照技能图谱逐层补能力先做最小实战再逐步加深11. 最佳实践与使用建议智能体编程听起来新颖但工程化的底层逻辑仍然是“小步快跑持续验证”。以下建议来自智能体项目开发和交付的通用经验值得在动手前过一遍。第一先跑通最小闭环。不要一开始就搭复杂的 Agent Framework先用最原始的 API 调用把“输入 → 模型 → 工具 → 输出”串通。最小闭环能帮你理解模型行为也能暴露出真正的瓶颈。第二提示词要有版本管理。提示词就是代码建议纳入 Git 管理每次修改记录效果变化。修改提示词前先跑一遍回归测试集避免改了一个问题带崩三个场景。第三工具调用必须有日志。模型到底调了什么工具、传了什么参数、返回了什么错误这些信息如果缺失排错会非常痛苦。建议每个工具内部都加入日志记录入参、出参、耗时和异常。第四评测集要持续扩充。把线上用户的失败案例逐步沉淀到测试集中形成“效果回归防线”。没有测试集的智能体项目后期迭代会越来越难。第五RAG 不是银弹。先确认业务问题适不适合用 RAG——知识库内容稳定、答案需要依据、模型容易幻觉这些场景更适合 RAG。如果只是简单问答也许提示词就够。第六安全和合规不能省。智能体涉及用户隐私、内部数据、第三方 API 调用时需要明确权限边界。涉及人脸、声音、版权素材等场景必须确认授权与合规要求。第七关于“软件工程能不能转机器视觉”这类问题。从技能图谱看软件工程转机器视觉不是不可能但需要补齐线性代数、图像处理、深度学习模型训练等技能重合部分是 Python 工程能力、数据管道和部署经验相比之下转智能体开发的重合度更高因为智能体编程的底座还是软件工程本身。选择哪个方向取决于想补的是“模型训练”还是“模型应用”的深度。12. 总结与下一步智能体编程时代的软件工程基础技能不是把老知识推倒重来而是在原有能力上增加“模型交互、知识增强、工具编排、评测监控”这一层新技能。这张能力图谱最有价值的点在于它把模糊的“会做智能体”拆成了可以逐项练习的工程技能。建议首先验证自己的第一层能力能否独立调用模型 API能否写清楚一个工具定义能否为一个简单问答场景设计一份可回归的测试集。这三个动作能做到就已经有一只脚迈进智能体编程的大门了。最容易踩的坑有两个一个是沉迷提示词技巧忽略了上下文管理另一个是只做 Demo不做评测和日志。智能体能不能上生产看的不是演示效果多惊艳而是出问题时能不能定位、能不能回滚、能不能持续改进。后续可以继续扩展的方向是把 RAG 从原型做到生产级把工具调用从单工具扩展到多工具编排把评测从人工看结果升级为自动化回归流水线。把这套链路跑熟之后低代码平台的变化、模型版本的变化、新框架的出现都不会影响你交付智能体系统的能力。