智能体编程时代：从低代码到代码的软件工程技能图谱

智能体编程这两年快速发展从最初“套一层提示词就挂出来”的玩具逐渐变成需要知识库、工具调用、工作流编排、效果评测和持续迭代的工程化方向。很多同学在社区里问“智能体编程到底要不要学软件工程”“低代码平台搭 Agent 是不是就不需要写代码了”“软件工程专业能不能转机器视觉”这些问题背后其实都有一个共同点大家缺少一张清晰的技能图谱不知道自己在哪个位置、下一步该补什么。本文会围绕“智能体编程时代的软件工程基础技能图谱”这一主题系统拆解智能体开发需要掌握的核心能力梳理从低代码搭建到代码工程化的完整路径并结合实际开发中的常见问题给出排查思路。无论你是刚接触智能体开发的新手还是已经有项目经验的开发者都能在本文中找到可对照的能力清单和可落地的实践方法。1. 智能体编程是什么为什么需要技能图谱1.1 智能体编程的本质智能体编程简单说就是让大语言模型不再只是一个“聊天问答框”而是成为一个能感知环境、调用工具、按流程完成多步骤任务的执行体。它和传统编程最大的区别是传统程序靠人写清楚每一步逻辑智能体则是在给定目标和约束后由模型自主生成路径并调用外部工具完成目标。用一个例子来理解传统程序实现“查询天气并提醒带伞”需要你写接口调用、写 if/else 判断、写提醒逻辑。智能体实现同样功能只需要你告诉它“帮我查天气如果下雨就提醒用户带伞”它自己决定调哪个天气接口、怎么判断下雨、怎么组织提醒文案。但“自主”不等于“没有约束”。如果没有清晰的提示词、正确的工具定义、合理的流程边界智能体很快就会失控答非所问、反复调用同一个接口、编造不存在的工具参数。这也就是为什么智能体开发仍然需要软件工程思维来兜底。1.2 为什么需要一张技能图谱技能图谱本质上是一张“能力地图”。它告诉你从哪里开始学。核心技能有哪些。每一项技能解决什么问题。技能之间如何串联成完整项目。现在智能体开发的资料非常多但高度碎片化。有人从提示词入门有人从工作流入门有人从模型 API 入门还有人是先接触了低代码平台。结果就是会拖拽工作流但看不懂代码会写提示词但不会设计知识库结构会调用 API 但不会做异常处理和日志追踪。技能图谱的作用就是把“会一点”变成“成体系”。1.3 本文适合谁本文主要面向以下读者刚接触智能体开发想系统了解需要学什么的新手。已经在低代码平台搭过几个 Agent想往代码开发进阶的开发者。软件工程相关专业学生想了解传统软件工程技能在 AI 时代如何迁移。对“软件工程能不能转机器视觉”“Python 在智能体开发中怎么用”等问题有困惑的同学。读完本文你会得到一张可落地的技能清单以及一套从低代码到代码的渐进入门路径。2. 智能体编程的基础技能全景2.1 提示词工程智能体的“表达力”提示词是智能体开发里最基础也最容易被低估的技能。很多人觉得提示词就是“跟 AI 说话说清楚一点”但在实际项目中提示词是智能体行为的第一约束。一个合格的系统提示词System Prompt至少应该包含以下内容模块作用示例角色定义明确智能体身份和回答风格“你是一名客服助手”任务目标说明智能体要完成什么“根据用户问题推荐商品”约束条件限制回答范围和行为边界“禁止回答与商品无关的问题”输出格式规定结果结构“以 JSON 格式输出”兜底策略遇到不确定情况怎么办“无法回答时引导转人工”看一个实际提示词模板你是一名电商售后客服助手。 你的任务 根据用户描述的问题判断问题类型并在选项中选择最合适的处理方案。 处理选项 1. 退货退款 2. 换货 3. 维修 4. 补发赠品 约束条件 - 只处理售后相关问题不回答商品推荐、物流时效等问题。 - 如果用户描述不在上述类别中请输出“转人工”。 输出格式 {type: 处理选项编号, reason: 判断理由}这个提示词有角色、有任务、有边界、有输出格式即使是一个简单的 API 调用也能达到不错的效果。反过来如果只写一句“你是客服助手”智能体很容易走偏。所以提示词工程的学习重点不是“会不会写”而是“能不能结构化表达”。这本质上是需求分析能力的体现也是软件工程基本功在 AI 时代的一种新形式。2.2 工具调用与 Function Calling如果说提示词决定了智能体的“嘴”工具调用决定了智能体的“手”。工具调用Function Calling / Tool Use是指让模型在对话过程中根据用户需求决定调用哪个外部函数并生成对应的参数。模型本身不执行函数它只负责“决定调用并给出参数”真正的执行仍然由你的代码完成。以 Python 调用 OpenAI 兼容接口为例工具调用通常分为三步定义工具结构也就是告诉模型有哪些函数可以用。将用户消息和工具定义一起发送给模型。判断模型返回的是普通回复还是工具调用请求如果请求了工具则执行本地函数并把结果返回给模型。下面是一个非常精简的示例思路需要根据你实际使用的 SDK 版本调整# 文件路径tool_call_demo.py # 说明这是一个演示工具调用流程的最小示例需根据实际接口调整 def get_weather(city: str) - str: 模拟天气查询函数 data {北京: 晴, 上海: 雨, 广州: 阴} return data.get(city, 未知) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ] messages [ {role: user, content: 北京今天天气怎么样} ] # 实际项目中这里会调用模型接口获得响应 # response client.chat.completions.create( # modelyour-model, # messagesmessages, # toolstools # ) # # 然后判断响应中是否包含 tool_calls 字段 # 如果有则执行 get_weather(city参数)再把结果追加到 messages 中工具调用的难点往往不在“调通”而在“定义清楚”。函数名、参数描述、返回值格式都会直接影响模型的选择稳定性。项目中比较常见的做法是参数尽量用枚举值约束函数描述里写清楚“什么时候调用”和“什么时候不要调用”。2.3 工作流编排与低代码模式工作流编排是把一个大任务拆成多个子步骤然后按顺序或条件组合执行。比如一个“客户咨询处理工作流”可以拆成意图识别 → 知识库检索 → 生成回答 → 人工复核。现在很多智能体开发平台都提供可视化的工作流编排能力也就是低代码/拖拽式开发。这块能力的价值是让不熟悉代码的同学也能快速搭建多步骤流程同时让熟悉代码的开发者摆脱重复工程。但有同学在社区里问为什么平台上的“低代码模式”入口找不到了这个现象其实并不少见。很多可视化平台为了统一产品体验会把原来的“低代码模式”合并进新版的工作流编辑器或项目模板中旧入口被调整是很常见的事情。遇到这种情况建议优先查看官方更新日志和文档确认是“入口迁移”还是“能力合并”而不是直接认为功能被下线。在大多数情况下新版工作流在节点能力和调试体验上会比旧版更强功能本身并没有消失。这里给出三种主流开发形态的对比开发形态上手难度灵活性适合场景纯提示词低低简单问答、角色扮演低代码工作流中中多步骤任务、业务流程自动化代码开发高高复杂业务、企业级应用低代码和代码开发不是二选一的关系。更推荐的路径是先用低代码快速验证流程逻辑等复杂度上升后再切换到代码开发把工作流中的节点变成真正可维护的代码模块。3. 软件工程基本功依然是底座3.1 需求拆解与系统设计很多同学学智能体开发时会忽略一个事实智能体只是一个组件不是整个系统。一个完整的智能体应用仍然需要需求分析、系统设计、数据设计、接口设计和测试验收。举个例子你要做一个“合同审查智能体”。如果只盯住“让 AI 审查合同”你会发现做出来的是一个效果不稳定的玩具。但如果你按软件工程思路来拆解流程会完全不同需求层用户是谁是法务还是销售审查目标是风险提醒还是合规检查输入是 PDF 还是 Word数据层需要哪些合同模板条款知识库怎么建标注数据从哪来交互层用户在对话框里上传文件还是通过 API 接入现有 OA 系统评估层怎么判断 AI 找出的风险点准不准谁来验收运维层模型升级了怎么办知识库怎么更新错误怎么追踪这些思考路径本质上就是《软件工程导论》里讲的常规流程可行性分析、需求分析、概要设计、详细设计、编码、测试、维护。只不过“编码”这一环节的形态变了有时候是写 Python 代码有时候是配置工作流。3.2 Python 在智能体开发中的位置考虑到“python软件工程”这个搜索热度一直很高这里单独说一下 Python 的价值。这不是说不会 Python 就不能做智能体开发——低代码平台完全可以让你先跑通业务。但如果你的目标是做更复杂的应用Python 几乎是绕不开的。原因有三个主流 AI SDK 和框架都以 Python 优先。数据处理、知识库构建、爬虫、自动化脚本等周边能力Python 生态最齐全。代码开发智能体时最常见的工程语言就是 Python。对软件工程学习者来说Python 不需要学到“精通 C 源码”那个深度但以下基础能力必须具备# 文件路径basic_python_skills.py # 说明智能体开发中最高频的几种 Python 操作 # 1. 字典和列表操作解析模型返回的 JSON 结构 result {type: 2, reason: 商品包装破损} if result.get(type) 2: print(处理方案换货) # 2. 异常处理调用外部接口时的容错 try: response requests.post(http://your-api, json{text: hello}, timeout5) response.raise_for_status() except requests.exceptions.Timeout: print(接口超时) except requests.exceptions.RequestException as e: print(f请求失败{e}) # 3. 文件读写读取知识库文本 with open(knowledge_base.txt, r, encodingutf-8) as f: content f.read()Python 的学习重点应该放在“能独立写脚本处理数据”和“能看懂开源项目代码”这两个目标上而不是沉迷语法细节。3.3 从智能体开发反推软件工程导论你可能听说过“软件工程能转机器视觉吗”这样的问题。这类问题本质上是在问“我现在学的技能还能不能迁移”。实际上软件工程的核心能力——抽象建模、架构设计、代码规范、测试方法、性能优化、团队协作——在任何技术方向都有迁移价值智能体开发也不例外。甚至可以说智能体开发让软件工程导论里很多“学了不知道怎么用”的知识变得具体了“高内聚低耦合”对应的是提示词模块、工具模块、知识库模块要分离。“面向接口编程”对应的是模型供应商可替换OpenAI 兼容 API 可以平滑切换。“单元测试”对应的是对工具函数做最小测试而不是每次都全流程联调。“版本控制”对应的是提示词也要做版本管理因为改一句话效果可能就变了。这些联系说明不要因为技术热点变化就否定自己正在学的软件工程基础。相反基础越扎实在 AI 时代切换技术方向的时候越从容。4. 一份可落地的智能体开发技能图谱4.1 技能图谱总览把上面讨论的内容汇总可以画出一份技能图谱用表格表达能力域具体技能优先级掌握程度基础认知LLM API 调用、Token 概念、模型选择高会用即可提示词工程系统提示词、少样本示例、输出约束高熟练工具调用Function Calling、参数定义、异常处理高熟练数据与知识库文档解析、向量化、检索召回、知识更新高掌握核心流程工作流编排节点设计、条件分支、低代码与代码混合中至少掌握一种平台代码工程Python 脚本、接口封装、配置管理中高能独立写脚本测试评估回归测试、效果评估、Bad Case 分析高必须掌握安全合规鉴权、防注入、内容安全、隐私保护高必须掌握运维监控日志、链路追踪、模型成本控制中了解即可4.2 按阶段划分的学习路径第一阶段入门期目标是跑通一个“调 API 的问答程序”。学习 Python 基础语法。学会调用 LLM API理解 user、assistant、system 三种消息角色。掌握 print、日志、异常捕获等基础调试手段。第二阶段能力期目标是做出“会调用工具的智能体”。学习 Function Calling 的完整流程。学习知识库的构建与检索。学习工作流平台的节点配置。第三阶段工程期目标是做出“可上线、可维护的智能体应用”。学习提示词版本管理。学习接口性能优化和成本控制。学习日志追踪和效果评测体系。学习安全边界设计与权限控制。第四阶段架构期目标是设计多智能体协作系统。学习 Agent 之间的通信协议。学习任务拆分与结果聚合。学习失败重试与降级方案。4.3 技能与常见方向的对应想做的方向重点技能需要弱化的内容智能客服提示词、知识库、多轮对话管理复杂算法RAG 应用文档解析、向量检索、召回排序模型训练自动化流程工作流编排、工具调用、API 集成模型底层原理多智能体系统Agent 架构、任务编排、状态管理单个模型调优机器视觉方向Python、数据处理、深度学习基础Agent 相关细节这样看会很清楚软件工程转机器视觉核心迁移的是 Python 功底、数据处理能力和工程实践经验而不是“软件工程”这个四个字本身。5. 实战从低代码到代码搭建一个知识问答智能体这一节我们用一个完整案例把上面的技能串起来做一个“公司内部制度知识问答智能体”。先描述需求和设计再分别给出低代码和代码两种实现路径。5.1 需求分析与设计需求员工向智能体提问例如“年假怎么休”“加班工资怎么算”。智能体基于公司制度文档回答。如果文档中没有答案必须引导员工联系 HR不能自己编造。按前面讲的设计思路拆解数据层准备一个“员工手册.md”作为知识来源。检索层将文档切块并向量化用户提问时检索最相关的片段。生成层将检索到的片段和用户问题组合成提示词交给 LLM 生成回答。兜底层判断检索结果是否满足相关度阈值不满足则回复“建议联系 HR”。5.2 方案 A低代码平台实现在多数智能体开发平台中操作流程基本一致创建智能体填写名称和简介。配置系统提示词写入角色和约束。添加知识库上传员工手册文档。开启“知识库检索增强”选项。编辑不满足时的兜底回复。发布到测试环境进行问答验证。提示词可以这样写你是一名公司内部行政助手。 你的知识来源是“员工手册”知识库请严格根据检索到的内容回答。 要求 1. 回答时先列出依据再给出结论。 2. 如果检索内容不足以回答问题请回复“该问题需要 HR 人工确认建议拨打 HR 分机 8000 咨询。” 3. 不要编造制度内容。用低代码实现的好处是 30 分钟就能看到效果。但它也有明显短板检索效果不可控、日志不完整、不方便做批量回归测试。所以方案 A 更适合“快速验证”不适合“正式上线”。5.3 方案 B代码开发实现代码开发的核心逻辑是读取文档 → 切块 → 向量化 → 用户提问时检索 → 拼接提示词 → 返回回答。这里给出一个最简可运行的工程示意建议按你的实际技术栈调整# 文件路径simple_rag.py # 说明知识问答智能体的核心流程示例简化版 def load_and_split_document(path: str) - list: 读取文档并按段落切块 with open(path, r, encodingutf-8) as f: text f.read() chunks [p.strip() for p in text.split(\n\n) if p.strip()] return chunks def retrieve(chunks: list, question: str, top_k: int 2) - list: 简化检索基于关键词匹配返回最相关的文本块 生产环境应替换为向量检索或混合检索 scored [] for i, chunk in enumerate(chunks): score sum(chunk.count(word) for word in question.split()) scored.append((score, i, chunk)) scored.sort(keylambda x: x[0], reverseTrue) return [item[2] for item in scored[:top_k]] def build_prompt(question: str, contexts: list) - str: 拼接检索结果和用户问题生成最终提示词 context_text \n\n.join(contexts) prompt f你是一名公司内部行政助手。 请根据以下资料回答问题。如果资料中找不到答案请回复 “该问题需要 HR 人工确认建议拨打 HR 分机 8000 咨询。” 资料 {context_text} 问题{question} return prompt if __name__ __main__: chunks load_and_split_document(employee_handbook.md) retry_result retrieve(chunks, 年假怎么休) prompt build_prompt(年假怎么休, retry_result) print(prompt) # 拿到 prompt 后下一步是调用 LLM API # response client.chat.completions.create( # modelyour-model, # messages[{role: user, content: prompt}] # )这个示例把“检索”和“生成”两个环节解耦了便于后续优化。正式项目里切块长度、检索算法、相关度阈值、重排序、多路召回等都需要单独设计和评测。5.4 运行与验证运行前先准备一个简单的员工手册# 员工手册节选 ## 年假 工作满 1 年不满 10 年的员工每年享受 5 天年假。 ## 加班 工作日加班按 1.5 倍工资计算法定节假日加班按 3 倍工资计算。 ## 报销 差旅报销需在行程结束后 7 个工作日内提交申请。运行程序python simple_rag.py预期的输出是你是一名公司内部行政助手。 请根据以下资料回答问题。如果资料中找不到答案请回复 “该问题需要 HR 人工确认建议拨打 HR 分机 8000 咨询。” 资料 工作满 1 年不满 10 年的员工每年享受 5 天年假。 问题年假怎么休这说明检索环节正常工作了。下一步接入 LLM API就能得到最终回答。5.5 方案对比与选择建议维度低代码方案代码方案开发速度快慢可定制性低高可测试性中高可运维性依赖平台自主可控适合阶段原型验证、小型项目生产环境、复杂项目成本平台按用量收费模型 API 成本 开发成本实际项目里如果你还在验证业务可行性建议先用低代码把效果和流程跑通如果业务稳定了再逐渐把关键链路迁移到代码实现补上评测、监控和版本管理。6. 常见问题与排查思路6.1 平台低代码模式入口找不到这是社区里最常被问的问题之一。现象通常是之前能看到“低代码”或“可视化编辑”入口更新后找不到了。可能原因排查思路平台更新导致入口迁移查看官方文档、更新日志搜索新版本功能入口功能被合并进新版工作流检查新版工作流编辑器是否覆盖原功能账号权限或项目类型不同检查当前项目是否需要新建“工作流项目”才能看到浏览器缓存或页面版本不一致强制刷新、清除缓存后重试如果确认功能只是入口变化直接按新入口操作即可不需要回退版本。如果你依赖的某个能力真的被下线了建议评估替代方案并尽早规划代码实现的迁移路径。6.2 智能体回答不准确这个问题几乎每个做智能体的人都会遇到。常见原因按出现频率排序是提示词约束不够模型自由发挥空间太大。知识库内容不完整或分块不合理。检索结果和问题不相关模型拿不到有效上下文。没有设置相关度阈值低质量检索结果也被送入模型。排查时建议先做一个控制变量实验固定提示词只换知识库内容看效果是否变化。固定知识库只改提示词看效果是否变化。打开日志打印每一步检索到的文本块人工判断检索质量。如果每次输出的结果不稳定可以尝试降低模型的 temperature 参数如果回答经常包含无关信息重点检查提示词里的约束部分。6.3 工具调用报错或参数错误工具调用失败的典型表现是模型返回了工具调用请求但参数格式和你定义的函数不匹配。问题现象常见原因解决思路模型调用不存在的函数工具描述不清在 description 中写清触发条件参数传错类型parameters 定义不严格使用枚举、严格类型约束函数执行后报错未处理接口异常工具函数内部增加异常捕获模型反复调用同一工具缺少终止条件在提示词中说明调用次数上限工具调用的核心调试技巧是把模型返回的原始响应完整打印出来。很多人直接拿处理好的结果看反而定位不到问题。6.4 发布后的效果退化问题开发环境测试时效果不错上线后效果变差这是智能体项目最常见的生产环境问题。常见原因真实用户问题分布和测试集差异太大。知识库更新后没有重新评估整体效果。模型侧行为更新同样的提示词效果发生变化。上游接口变慢或报错智能体在超时后返回兜底文案。解决办法是建立“上线前回归测试”机制。准备一个包含 50~100 条测试用例的评测集每次改提示词、改知识库、换模型后先跑一遍回归测试再考虑上线。7. 从智能体开发到工程化的最佳实践7.1 提示词也要版本管理代码有 Git提示词也应该有版本管理。这是很多团队最容易忽略的环节。建议至少做到提示词作为独立文件存放不要直接写在数据库或代码字符串里。每次修改记录变更原因。上线前用固定的测试集跑回归。推荐把提示词和配置统一放到配置文件中例如# 文件路径agent_prompt.yaml system_prompt: | 你是一名公司内部行政助手。 知识来源是“员工手册”知识库请严格根据检索内容回答。 temperature: 0.2 max_tokens: 500 retrieval_top_k: 3 relevance_threshold: 0.5配置文件的好处是提示词调整、模型参数调整不需要改代码只需出新的配置版本。7.2 可观测性与日志生产环境的智能体应用必须能回答三个问题用户问了一句什么系统检索到了什么模型最终回答了什么这三点是最低限度的日志要求。更完整的话还需要记录模型调用耗时和 Token 消耗。每次调用的成本。工具调用的入参和出参。兜底策略的触发次数。日志记录时注意脱敏不要记录用户隐私信息。7.3 安全与权限边界智能体接入生产环境后安全问题会显著放大。核心关注点包括提示词注入用户可能在输入中塞入“忽略你之前的指令”等文本需要做输入校验和输出过滤。工具权限智能体能调用的工具必须是用户身份允许范围内的。数据权限知识库里的内容不能对所有用户无差别开放。内容安全对生成结果做敏感词和格式校验。这里特别提醒配置工具调用权限时遵循最小权限原则。不要给智能体一个“可以删除所有订单”的权限即使你只在测试环境验证也要保持谨慎。7.4 渐进式复杂度控制智能体项目最大的风险是“过度设计”。很多团队一上来就要做多智能体协作、复杂记忆机制、自进化系统结果连最基础的检索质量都没过关。更稳妥的路线是第一步先做一个最简单的“提示词 知识库”的问答机器人。第二步加入评测集把效果量化出来。第三步发现问题后再逐步加入工具调用、工作流、多轮记忆。第四步当单 Agent 确实无法满足需求时再考虑多智能体架构。每一步都建立在真实数据和评测结果之上而不是靠想象堆功能。8. 总结与下一步行动本文从“智能体编程需要什么技能”这个问题出发梳理了提示词工程、工具调用、工作流编排、Python 工程基础、知识库构建、效果评测等核心能力并结合“低代码模式入口消失”“回答不准确”“工具调用报错”等真实场景给出了排查思路。最后通过一个知识问答智能体的实战案例演示了从低代码验证到代码开发的完整路径。如果你想把这篇文章转化成实际能力我的建议是不要急着学“多智能体系统”“LangChain 架构”这些偏后期的内容。先把基础链路走通——准备一份文档、写一个简单的检索函数、封装一次 LLM 调用、建立一个 20 条用例的评测集。这个最小闭环跑通之后再对照技能图谱查漏补缺。软件工程的核心能力在智能体时代没有过时只是换了一种表现形式。真正的竞争力不是背下某个框架的 API而是能清晰地定义问题、设计流程、验证效果并持续迭代。掌握了这个思路无论前端还是转向机器视觉方向你都能快速迁移。