这次我们不看某个开源模型的跑分也不聊平台新功能先看一类最近非常常见的视频题材标题写着“POV今天早上AI 取代了我的工作”。视频里通常是一个打工人刚打开电脑把当天的工作全部丢给一个 AI 助手几分钟后周报、会议纪要和客户邮件草稿全部生成完毕。画面很爽弹幕在讨论“那我是不是明天就要失业了”。但作为一个长期在做本地部署和工程化的人我更关心的不是剧情而是这件事的技术本质视频里那套“AI 自动完成工作”的流程拆开之后到底是什么是简单的 LLM 对话还是 Agent 工作流、工具调用、批量任务和 API 编排的组合能不能在真实业务里复现需要什么硬件和软件条件如果我现在想在自己电脑上搭一个最小可运行的“AI 自动化助手”应该从哪里开始这篇文章会把这个问题讲透。我会先拆解这类视频背后的技术栈再给出一套通用的 AI 应用开发与本地部署验证路径环境准备、Agent 工作流启动、功能测试、接口 API 调用、批量任务、资源占用观察和常见问题排查。内容偏工程实践不渲染焦虑不吹效果目标只有一个让你看完之后能判断这玩意儿到底值不值得试以及怎么用最小的成本开始试。1. 核心能力速览拆解“AI 取代工作”视频的技术栈先不评价视频叙事只看技术。一个号称“AI 取代了我的工作”的演示通常在几分钟内展示这些动作读取邮件、整理会议记录、生成日报/周报、草拟回复、汇总 Excel、做 PPT 大纲、安排日程、甚至自动发消息。这些动作看起来是“一个 AI 干的”实际拆开后是多种能力的串联。视频展示能力背后对应技术真实落地难度理解任务指令大语言模型LLM对话能力低读取文档、图片、PDF多模态模型 / OCR / 文档解析中自动操作软件或网页工具调用Function Calling、RPA中高连续多步完成任务Agent 循环感知 → 决策 → 行动 → 反馈高按时间自动触发定时任务 / 消息队列 / Webhook低一次处理大量文件批量任务脚本 API 并发调用中回答基于私有知识RAG检索增强生成高从这张表能看出关键结论短视频里的“AI 取代工作”本质不是某一个模型突然变强而是工作流从“人在工具之间切换”变成了“程序在 API 之间切换”。真正值钱的部分不是单次对话的流畅度而是任务拆解、工具打通和异常处理。另外输入材料里提到了一个开源项目 AI 小镇my_ai_town。这类项目把多个智能体放进一个模拟空间每个智能体有独立的记忆、状态和行为逻辑。它和“取代工作”的视频有一个共同点多个 Agent 之间的协作编排已经不再停留在论文里而是逐渐变成可运行的工程代码。理解了这个背景再看各类“AI 自动化”演示你会更清楚地知道哪些可以复现哪些只是剪辑效果。2. 适用场景与使用边界先分清“可自动化”和“不该自动化”2.1 适合自动化的环节从工程实践看下面这些环节最容易先被 AI 自动化接管信息整理类会议纪要转结构化文档、邮件分类与摘要、调研资料汇总。文档初稿类周报初稿、PPT 大纲、方案框架、代码 README。数据清洗类CSV/Excel 字段补充、格式统一、重复数据标记。客服工单类FAQ 匹配、工单优先级初判、标准话术草拟。代码脚手架类接口模板生成、单元测试占位、SQL 初步编写。这些任务的共同特点是输入和输出边界相对清晰错误容忍度可控而且最后都有人工复核节点。2.2 不适合自动化的环节需要法律或财务责任判断的决策。涉及重大人事、薪酬、合规结论的最终输出。面向真实用户且无人工审核的对外发布内容。涉及敏感个人信息、未授权数据、版权素材的处理。这里必须强调如果你要把 AI 接进真实的业务数据流请先确认三件事是否有明确授权是否对数据脱敏是否有人工审批出口。尤其是处理邮件、客服会话、内部文档时账号权限和数据隐私不是技术问题是合规底线。别为了“演示效果”把真实客户数据直接喂给外部 API。2.3 从“替代”视角切到“协作”视角更合理的定位是AI 负责完成“信息到信息的转换”人类负责“定义任务、确认标准和承担结果”。视频里那种“早上醒来发现工作被做完了”的叙事省略了前期的流程设计、测试和兜底机制。作为技术人正确的姿势是把 AI 当做一个需要编排和治理的新同事而不是一个魔法黑箱。3. AI 模型部署与 Agent 工作流环境准备如果你想自己搭一个最小可运行的自动化工作流先按下面的清单准备环境。这里给的是通用检查点具体版本取决于你选择的模型服务方式。检查项推荐配置说明操作系统Linux / macOS / WindowsLinux 相对省心Windows 需注意路径和进程管理Python3.10 及以上AI 工程实践常用版本建议用 venv 隔离包管理工具pip / uv / poetry推荐 uv安装快、依赖管理清晰Docker可选部署模型服务或 Redis 队列时更方便模型服务本地部署vLLM/Ollama或云端 API首次验证建议直接用云端 API降低环境复杂度GPU按本地模型需求选择如果只调接口CPU 也能完成流程测试磁盘空间至少预留 20GB本地模型普遍较大还要留日志和测试素材空间端口8000、7860、8080 等提前确认不被占用基础环境验证脚本python --version pip --version nvidia-smi # 如果使用本地 GPU观察驱动和显存状态如果你选择本地部署模型常见思路是用一个 OpenAI 兼容接口服务比如 vLLM 或 Ollama。这类服务会把模型包装成标准 HTTP 接口后续所有 Agent 代码都走同一个协议替换模型时不需要改业务逻辑。接口地址一般是http://127.0.0.1:8000/v1/chat/completions没有现成的本地模型服务时先用云端 API 完成流程验证再把 endpoint 切到本地这是最稳妥的起步方式。不要一上来就追求全本地化。4. 从“演示”到“工程落地”搭建最小 Agent 工作流4.1 场景设定我们做一个很小的自动化流程模拟视频里“AI 帮我写工作日报”的效果但加一个很多人忽略的步骤人工确认。流程如下定时读取一个目录下的原始工作记录比如散装笔记。调用 LLM 把笔记整理成结构化的日报草稿。输出 JSON 文件到drafts/目录。程序只负责生成草稿不自动发送给任何人。这样做既能体验 AI 自动化的效率又不会踩“自动发消息给领导”这种危险 demo 的坑。4.2 核心代码调用 OpenAI 兼容接口import os import json import httpx API_URL http://127.0.0.1:8000/v1/chat/completions API_KEY os.environ.get(AI_API_KEY, EMPTY) SYSTEM_PROMPT 你是一个职场助理。你的任务是把零散的工作笔记整理成结构化日报。 日报必须包含今日完成事项、遇到的问题、明日计划。 输出必须是 JSON 对象不要输出其他文字。 def generate_daily_report(note_text: str, model: str qwen2.5:7b) - dict: payload { model: model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请整理以下工作笔记\n{note_text}} ], temperature: 0.3, response_format: {type: json_object} } headers {Authorization: fBearer {API_KEY}} try: resp httpx.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content) except Exception as e: print(f[ERROR] generate failed: {e}) return {error: str(e)} if __name__ __main__: sample_note 上午改登录接口 bug原因是 token 过期判断写反了。 下午评审了订单导出需求确认用异步任务实现。 明天跟进测试环境部署。 result generate_daily_report(sample_note) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码不需要改就能对着任意 OpenAI 兼容接口跑。如果你用的是 OpenAI 官方 API把API_URL换成官方地址把API_KEY换成真实 key 即可。4.3 JSON 配置文件管理把目录、模型、温度这类参数抽到配置里避免在代码里写死{ input_dir: ./notes, output_dir: ./drafts, model: qwen2.5:7b, temperature: 0.3, max_retries: 3, batch_size: 5 }import json with open(config.json, r, encodingutf-8) as f: CONFIG json.load(f) INPUT_DIR CONFIG[input_dir] OUTPUT_DIR CONFIG[output_dir]4.4 启动方式如果模型服务是本地部署的先启动模型服务再运行业务脚本# 启动本地模型服务以 Ollama 为例实际命令取决于你的部署方式 ollama serve # 另一个终端运行业务脚本 python daily_report_agent.py如果直接用云端 API直接运行脚本即可。启动后能看到脚本生成drafts/目录里面是格式化后的日报 JSON这就是“AI 自动化工作流”的最简可运行版本。5. AI 应用开发中的功能测试与效果验证工作流跑通之后重点不是看它生成得“像不像”而是测试它的稳定性和边界。下面是一套可以直接照做的测试方案。测试维度测试方法判断成功标准指令理解输入不同风格的工作笔记输出结构基本稳定不丢失关键事项输出格式连续调用 20 次检查 JSON 能否被解析JSON 解析成功率 100%多轮稳定性相同输入跑多次对比结果差异核心信息一致表达差异可接受长文本输入一篇超过 3000 字的会议记录不截断、不遗漏章节结构异常输入输入空文本、纯符号、乱码不崩溃返回可读的错误提示批量任务一次性处理 10 份笔记文件全部生成结果失败文件有记录5.1 批量文件处理脚本在真实 AI 工程实践里单次调用只是第一步批量处理才是常态。下面这个脚本会遍历notes/目录下的所有.md文件逐条调用接口并保存结果到drafts/import json import time import pathlib from daily_report_agent import generate_daily_report def process_dir(input_dir: str, output_dir: str, batch_size: int 5): input_path pathlib.Path(input_dir) output_path pathlib.Path(output_dir) output_path.mkdir(parentsTrue, exist_okTrue) files list(input_path.glob(*.md)) total len(files) success_count 0 for i in range(0, total, batch_size): batch files[i:i batch_size] for file in batch: note_text file.read_text(encodingutf-8) result generate_daily_report(note_text) out_file output_path / f{file.stem}_report.json out_file.write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8 ) if error not in result: success_count 1 else: print(f[WARN] {file.name} failed) time.sleep(1) # 控制并发避免触发限流 print(fprogress: {min(i batch_size, total)}/{total}) print(fdone, success: {success_count}/{total}) if __name__ __main__: process_dir(notes, drafts, batch_size3)5.2 预期输出与失败排查运行成功后drafts/下会出现类似这样的 JSON{ 今日完成事项: [ 修复登录接口 token 过期判断问题, 评审订单导出需求确认使用异步任务 ], 遇到的问题: [ 前期 token 过期判断逻辑写反已修正 ], 明日计划: [ 跟进测试环境部署 ] }如果输出不是有效的 JSON先检查两件事模型是否支持response_format的 JSON 模式。不支持时去掉该字段改在 system prompt 里强制输出 JSON。上下文是否过长。超长输入可能导致输出被截断先缩短输入再测试。6. 接口 API 与批量任务设计6.1 通用 API 调用示例无论你用的是本地模型还是云端 API标准接口调用方式都类似curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer EMPTY \ -d { model: qwen2.5:7b, messages: [{role: user, content: 写一句话介绍你的功能}], temperature: 0.7 }这是最通用的 OpenAI 兼容调用格式适配大多数本地和云端模型服务。如果你的接口不是这个协议需要按实际项目文档调整。6.2 批量任务的队列与重试设计当任务数量从 10 个涨到 1000 个就不能再用简单的for循环了。建议至少做到任务列表持久化把待处理文件记录到 JSONL 或数据库。失败重试对限流、超时、网络抖动做重试一般重试 3 次。幂等输出同一次输入重复执行不产生重复结果输出文件名固定即可。日志完整记录每个文件的调用时间、token 数、成功与否。示例任务记录格式{ task_id: 20250218_001, input_file: notes/meeting_0217.md, status: pending, retry_count: 0, created_at: 2025-02-18T10:00:0008:00 }需要说明这个格式是我在项目里常用的通用模板并不属于某个固定平台规范。你在工程化时可以直接复制再按自己的业务字段修改。7. AI 工程实践资源占用与性能观察7.1 怎么观察资源占用如果你跑的是本地模型至少要看两样东西GPU 显存和 CPU/内存使用。nvidia-smi -l 2 # 每 2 秒刷新一次 GPU 状态也可以直接用 Python 在脚本里采样显存import subprocess def get_gpu_memory(): result subprocess.run( [nvidia-smi, --query-gpumemory.used,memory.total, --formatcsv], capture_outputTrue, textTrue ) print(result.stdout)具体显存占用取决于模型参数量、量化精度、上下文长度和并发数我这里不写死某个数字原因是同一个模型在不同推理框架下的占用差异很大。正确做法是启动服务前记录一次空闲显存跑一次长文本任务后再看一次差值就是基础占用。7.2 CPU 推理和 GPU 推理的差异GPU 推理速度快适合交互式 Agent 和批量并发但显存有上限。CPU 推理部署环境简单适合小模型和低并发测试但性能明显偏慢。混合方案小模型用 CPU 也能跑大模型建议至少有独立 GPU。7.3 影响性能的关键参数上下文长度输入越长预填充耗时越长也是显存占用的主要推手。批量大小batch_size提高能提升吞吐但显存占用会同步上涨。温度采样temperature不影响速度但影响结果稳定性。并发请求并发过高会触发限流或 OOM第一次跑先并发 1再逐步提。7.4 降低资源占用的通用做法用小模型做初筛大模型做精修形成两级流水线。对超长文档先做切片只把相关片段送到模型里。减少不必要的 few-shot 示例节省 token。批量任务做好队列限流不要一次性塞满所有并发。8. AI 自动化工作流常见问题与排查方法问题现象可能原因排查方式解决方案接口调用超时模型推理慢或网络延迟查看服务日志和请求耗时调长 timeout缩小输入换更小模型返回内容不是 JSON模型不支持 JSON 模式检查接口文档和 response_format去掉该字段改为在提示词中强制指定生成内容出现幻觉长文本或上下文不足对比输入和输出检查信息是否多出增强提示词约束加入外部知识库人工复核关键内容批量任务中途卡住其中一个文件异常阻塞看日志找到卡住的文件给每个任务加超时和异常捕获GPU 显存不足模型过大或并发过高观察 nvidia-smi降低 batch_size换量化模型减少上下文端口被占用本地服务冲突lsof -i:8000或netstat -ano换端口或杀掉旧进程自动发送导致误发流程缺少人工审批检查代码中的发送逻辑先输出草稿人工确认后再发送输出质量不稳定提示词指令不清晰多次测试同一提示词固定 few-shot 示例降低 temperatureAI 幻觉是整个排查表里最值得注意的一项。工作流里只要有“自动把结果写进邮件/文档/工单”的环节就必须加一层校验让模型先输出可解析的数据再写一份人工可读摘要最后由人按下发送键。9. 给技术人的务实建议把 AI 改造成同事而不是对手看完这整条链路你应该已经意识到真正复杂的工作不是“让 AI 说一句话”而是把“一句话”变成一个可靠的工作流。下面几条是我在做 AI 应用开发和模型部署时的通用原则建议直接收藏。9.1 先跑最小闭环不要一上来就设计十个 Agent 的编排系统。先做单 Agent 单脚本 单文件夹跑通一个真实的日常任务。比如把“整理今日待办”做成脚本核心代码不超过 50 行。跑通之后再加定时触发、加队列、加多工具调用。9.2 输入、输出、日志分目录管理project/ ├── notes/ # 原始输入 ├── drafts/ # 生成结果 ├── logs/ # 运行日志 ├── config.json # 配置文件 └── scripts/ # 脚本目录这个结构适用于绝大多数自动化任务方便排查问题也方便后续接入 CI/CD 或定时任务。9.3 给关键流程加熔断如果 AI 连续失败 N 次应该停止批量调用而不是继续把错误结果写进文件。最简单的做法是在脚本里记一个失败计数器超过阈值就发一封告警邮件或打印明显错误。9.4 用好 AI 编程节省重复劳动与其担心“AI 取代编程”不如先把 AI 编程当作重构重复劳动的杠杆。通用代码模板、正则表达式、SQL 查询、配置脚本这类任务交给 AI 写了之后做 code review你会发现自己的注意力能更好地放在架构和边界设计上。9.5 明确人机分工所有 AI 自动化系统都建议遵守一个原则AI 生成内容人来做决策和发布。也就是说输出存在drafts/和输出直接发到公司群是两套完全不同的系统。前者是效率工具后者是风险敞口。10. 总结与下一步回到标题一个 POV 视频说“AI 今天早上取代了我的工作”。看完上面的技术拆解你应该能得出自己的结论AI 能取代的不是“你”而是“信息在工具间搬运”这个环节。真正的工作不会消失但工作流一定会被重新设计。对你来说最值得现在做的事很简单找一个小而重复的任务用文中第一节的能力拆解方法判断它属于哪一类然后照着第二节到第六节的环境准备、代码启动、功能测试和批量任务方案搭一个最小可运行版本。先验证输出格式再验证批量稳定性最后再考虑是否接入真实业务。最容易踩的坑有两个一是跳过人工审批直接全自动发布二是一开始就想做多 Agent 大系统。避开这两点AI 自动化工作流大概率能帮你省下不少重复劳动时间。如果你已经开始搭自己的第一套 Agent 工作流建议收藏这篇文章把环境准备清单、批量任务脚本和排查表复制下来跑完一个任务再回头看会发现很多细节只有在真机测试里才能暴露出来。 AI自动化工作流实战：从Agent到本地部署
这次我们不看某个开源模型的跑分也不聊平台新功能先看一类最近非常常见的视频题材标题写着“POV今天早上AI 取代了我的工作”。视频里通常是一个打工人刚打开电脑把当天的工作全部丢给一个 AI 助手几分钟后周报、会议纪要和客户邮件草稿全部生成完毕。画面很爽弹幕在讨论“那我是不是明天就要失业了”。但作为一个长期在做本地部署和工程化的人我更关心的不是剧情而是这件事的技术本质视频里那套“AI 自动完成工作”的流程拆开之后到底是什么是简单的 LLM 对话还是 Agent 工作流、工具调用、批量任务和 API 编排的组合能不能在真实业务里复现需要什么硬件和软件条件如果我现在想在自己电脑上搭一个最小可运行的“AI 自动化助手”应该从哪里开始这篇文章会把这个问题讲透。我会先拆解这类视频背后的技术栈再给出一套通用的 AI 应用开发与本地部署验证路径环境准备、Agent 工作流启动、功能测试、接口 API 调用、批量任务、资源占用观察和常见问题排查。内容偏工程实践不渲染焦虑不吹效果目标只有一个让你看完之后能判断这玩意儿到底值不值得试以及怎么用最小的成本开始试。1. 核心能力速览拆解“AI 取代工作”视频的技术栈先不评价视频叙事只看技术。一个号称“AI 取代了我的工作”的演示通常在几分钟内展示这些动作读取邮件、整理会议记录、生成日报/周报、草拟回复、汇总 Excel、做 PPT 大纲、安排日程、甚至自动发消息。这些动作看起来是“一个 AI 干的”实际拆开后是多种能力的串联。视频展示能力背后对应技术真实落地难度理解任务指令大语言模型LLM对话能力低读取文档、图片、PDF多模态模型 / OCR / 文档解析中自动操作软件或网页工具调用Function Calling、RPA中高连续多步完成任务Agent 循环感知 → 决策 → 行动 → 反馈高按时间自动触发定时任务 / 消息队列 / Webhook低一次处理大量文件批量任务脚本 API 并发调用中回答基于私有知识RAG检索增强生成高从这张表能看出关键结论短视频里的“AI 取代工作”本质不是某一个模型突然变强而是工作流从“人在工具之间切换”变成了“程序在 API 之间切换”。真正值钱的部分不是单次对话的流畅度而是任务拆解、工具打通和异常处理。另外输入材料里提到了一个开源项目 AI 小镇my_ai_town。这类项目把多个智能体放进一个模拟空间每个智能体有独立的记忆、状态和行为逻辑。它和“取代工作”的视频有一个共同点多个 Agent 之间的协作编排已经不再停留在论文里而是逐渐变成可运行的工程代码。理解了这个背景再看各类“AI 自动化”演示你会更清楚地知道哪些可以复现哪些只是剪辑效果。2. 适用场景与使用边界先分清“可自动化”和“不该自动化”2.1 适合自动化的环节从工程实践看下面这些环节最容易先被 AI 自动化接管信息整理类会议纪要转结构化文档、邮件分类与摘要、调研资料汇总。文档初稿类周报初稿、PPT 大纲、方案框架、代码 README。数据清洗类CSV/Excel 字段补充、格式统一、重复数据标记。客服工单类FAQ 匹配、工单优先级初判、标准话术草拟。代码脚手架类接口模板生成、单元测试占位、SQL 初步编写。这些任务的共同特点是输入和输出边界相对清晰错误容忍度可控而且最后都有人工复核节点。2.2 不适合自动化的环节需要法律或财务责任判断的决策。涉及重大人事、薪酬、合规结论的最终输出。面向真实用户且无人工审核的对外发布内容。涉及敏感个人信息、未授权数据、版权素材的处理。这里必须强调如果你要把 AI 接进真实的业务数据流请先确认三件事是否有明确授权是否对数据脱敏是否有人工审批出口。尤其是处理邮件、客服会话、内部文档时账号权限和数据隐私不是技术问题是合规底线。别为了“演示效果”把真实客户数据直接喂给外部 API。2.3 从“替代”视角切到“协作”视角更合理的定位是AI 负责完成“信息到信息的转换”人类负责“定义任务、确认标准和承担结果”。视频里那种“早上醒来发现工作被做完了”的叙事省略了前期的流程设计、测试和兜底机制。作为技术人正确的姿势是把 AI 当做一个需要编排和治理的新同事而不是一个魔法黑箱。3. AI 模型部署与 Agent 工作流环境准备如果你想自己搭一个最小可运行的自动化工作流先按下面的清单准备环境。这里给的是通用检查点具体版本取决于你选择的模型服务方式。检查项推荐配置说明操作系统Linux / macOS / WindowsLinux 相对省心Windows 需注意路径和进程管理Python3.10 及以上AI 工程实践常用版本建议用 venv 隔离包管理工具pip / uv / poetry推荐 uv安装快、依赖管理清晰Docker可选部署模型服务或 Redis 队列时更方便模型服务本地部署vLLM/Ollama或云端 API首次验证建议直接用云端 API降低环境复杂度GPU按本地模型需求选择如果只调接口CPU 也能完成流程测试磁盘空间至少预留 20GB本地模型普遍较大还要留日志和测试素材空间端口8000、7860、8080 等提前确认不被占用基础环境验证脚本python --version pip --version nvidia-smi # 如果使用本地 GPU观察驱动和显存状态如果你选择本地部署模型常见思路是用一个 OpenAI 兼容接口服务比如 vLLM 或 Ollama。这类服务会把模型包装成标准 HTTP 接口后续所有 Agent 代码都走同一个协议替换模型时不需要改业务逻辑。接口地址一般是http://127.0.0.1:8000/v1/chat/completions没有现成的本地模型服务时先用云端 API 完成流程验证再把 endpoint 切到本地这是最稳妥的起步方式。不要一上来就追求全本地化。4. 从“演示”到“工程落地”搭建最小 Agent 工作流4.1 场景设定我们做一个很小的自动化流程模拟视频里“AI 帮我写工作日报”的效果但加一个很多人忽略的步骤人工确认。流程如下定时读取一个目录下的原始工作记录比如散装笔记。调用 LLM 把笔记整理成结构化的日报草稿。输出 JSON 文件到drafts/目录。程序只负责生成草稿不自动发送给任何人。这样做既能体验 AI 自动化的效率又不会踩“自动发消息给领导”这种危险 demo 的坑。4.2 核心代码调用 OpenAI 兼容接口import os import json import httpx API_URL http://127.0.0.1:8000/v1/chat/completions API_KEY os.environ.get(AI_API_KEY, EMPTY) SYSTEM_PROMPT 你是一个职场助理。你的任务是把零散的工作笔记整理成结构化日报。 日报必须包含今日完成事项、遇到的问题、明日计划。 输出必须是 JSON 对象不要输出其他文字。 def generate_daily_report(note_text: str, model: str qwen2.5:7b) - dict: payload { model: model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请整理以下工作笔记\n{note_text}} ], temperature: 0.3, response_format: {type: json_object} } headers {Authorization: fBearer {API_KEY}} try: resp httpx.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content) except Exception as e: print(f[ERROR] generate failed: {e}) return {error: str(e)} if __name__ __main__: sample_note 上午改登录接口 bug原因是 token 过期判断写反了。 下午评审了订单导出需求确认用异步任务实现。 明天跟进测试环境部署。 result generate_daily_report(sample_note) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码不需要改就能对着任意 OpenAI 兼容接口跑。如果你用的是 OpenAI 官方 API把API_URL换成官方地址把API_KEY换成真实 key 即可。4.3 JSON 配置文件管理把目录、模型、温度这类参数抽到配置里避免在代码里写死{ input_dir: ./notes, output_dir: ./drafts, model: qwen2.5:7b, temperature: 0.3, max_retries: 3, batch_size: 5 }import json with open(config.json, r, encodingutf-8) as f: CONFIG json.load(f) INPUT_DIR CONFIG[input_dir] OUTPUT_DIR CONFIG[output_dir]4.4 启动方式如果模型服务是本地部署的先启动模型服务再运行业务脚本# 启动本地模型服务以 Ollama 为例实际命令取决于你的部署方式 ollama serve # 另一个终端运行业务脚本 python daily_report_agent.py如果直接用云端 API直接运行脚本即可。启动后能看到脚本生成drafts/目录里面是格式化后的日报 JSON这就是“AI 自动化工作流”的最简可运行版本。5. AI 应用开发中的功能测试与效果验证工作流跑通之后重点不是看它生成得“像不像”而是测试它的稳定性和边界。下面是一套可以直接照做的测试方案。测试维度测试方法判断成功标准指令理解输入不同风格的工作笔记输出结构基本稳定不丢失关键事项输出格式连续调用 20 次检查 JSON 能否被解析JSON 解析成功率 100%多轮稳定性相同输入跑多次对比结果差异核心信息一致表达差异可接受长文本输入一篇超过 3000 字的会议记录不截断、不遗漏章节结构异常输入输入空文本、纯符号、乱码不崩溃返回可读的错误提示批量任务一次性处理 10 份笔记文件全部生成结果失败文件有记录5.1 批量文件处理脚本在真实 AI 工程实践里单次调用只是第一步批量处理才是常态。下面这个脚本会遍历notes/目录下的所有.md文件逐条调用接口并保存结果到drafts/import json import time import pathlib from daily_report_agent import generate_daily_report def process_dir(input_dir: str, output_dir: str, batch_size: int 5): input_path pathlib.Path(input_dir) output_path pathlib.Path(output_dir) output_path.mkdir(parentsTrue, exist_okTrue) files list(input_path.glob(*.md)) total len(files) success_count 0 for i in range(0, total, batch_size): batch files[i:i batch_size] for file in batch: note_text file.read_text(encodingutf-8) result generate_daily_report(note_text) out_file output_path / f{file.stem}_report.json out_file.write_text( json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8 ) if error not in result: success_count 1 else: print(f[WARN] {file.name} failed) time.sleep(1) # 控制并发避免触发限流 print(fprogress: {min(i batch_size, total)}/{total}) print(fdone, success: {success_count}/{total}) if __name__ __main__: process_dir(notes, drafts, batch_size3)5.2 预期输出与失败排查运行成功后drafts/下会出现类似这样的 JSON{ 今日完成事项: [ 修复登录接口 token 过期判断问题, 评审订单导出需求确认使用异步任务 ], 遇到的问题: [ 前期 token 过期判断逻辑写反已修正 ], 明日计划: [ 跟进测试环境部署 ] }如果输出不是有效的 JSON先检查两件事模型是否支持response_format的 JSON 模式。不支持时去掉该字段改在 system prompt 里强制输出 JSON。上下文是否过长。超长输入可能导致输出被截断先缩短输入再测试。6. 接口 API 与批量任务设计6.1 通用 API 调用示例无论你用的是本地模型还是云端 API标准接口调用方式都类似curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer EMPTY \ -d { model: qwen2.5:7b, messages: [{role: user, content: 写一句话介绍你的功能}], temperature: 0.7 }这是最通用的 OpenAI 兼容调用格式适配大多数本地和云端模型服务。如果你的接口不是这个协议需要按实际项目文档调整。6.2 批量任务的队列与重试设计当任务数量从 10 个涨到 1000 个就不能再用简单的for循环了。建议至少做到任务列表持久化把待处理文件记录到 JSONL 或数据库。失败重试对限流、超时、网络抖动做重试一般重试 3 次。幂等输出同一次输入重复执行不产生重复结果输出文件名固定即可。日志完整记录每个文件的调用时间、token 数、成功与否。示例任务记录格式{ task_id: 20250218_001, input_file: notes/meeting_0217.md, status: pending, retry_count: 0, created_at: 2025-02-18T10:00:0008:00 }需要说明这个格式是我在项目里常用的通用模板并不属于某个固定平台规范。你在工程化时可以直接复制再按自己的业务字段修改。7. AI 工程实践资源占用与性能观察7.1 怎么观察资源占用如果你跑的是本地模型至少要看两样东西GPU 显存和 CPU/内存使用。nvidia-smi -l 2 # 每 2 秒刷新一次 GPU 状态也可以直接用 Python 在脚本里采样显存import subprocess def get_gpu_memory(): result subprocess.run( [nvidia-smi, --query-gpumemory.used,memory.total, --formatcsv], capture_outputTrue, textTrue ) print(result.stdout)具体显存占用取决于模型参数量、量化精度、上下文长度和并发数我这里不写死某个数字原因是同一个模型在不同推理框架下的占用差异很大。正确做法是启动服务前记录一次空闲显存跑一次长文本任务后再看一次差值就是基础占用。7.2 CPU 推理和 GPU 推理的差异GPU 推理速度快适合交互式 Agent 和批量并发但显存有上限。CPU 推理部署环境简单适合小模型和低并发测试但性能明显偏慢。混合方案小模型用 CPU 也能跑大模型建议至少有独立 GPU。7.3 影响性能的关键参数上下文长度输入越长预填充耗时越长也是显存占用的主要推手。批量大小batch_size提高能提升吞吐但显存占用会同步上涨。温度采样temperature不影响速度但影响结果稳定性。并发请求并发过高会触发限流或 OOM第一次跑先并发 1再逐步提。7.4 降低资源占用的通用做法用小模型做初筛大模型做精修形成两级流水线。对超长文档先做切片只把相关片段送到模型里。减少不必要的 few-shot 示例节省 token。批量任务做好队列限流不要一次性塞满所有并发。8. AI 自动化工作流常见问题与排查方法问题现象可能原因排查方式解决方案接口调用超时模型推理慢或网络延迟查看服务日志和请求耗时调长 timeout缩小输入换更小模型返回内容不是 JSON模型不支持 JSON 模式检查接口文档和 response_format去掉该字段改为在提示词中强制指定生成内容出现幻觉长文本或上下文不足对比输入和输出检查信息是否多出增强提示词约束加入外部知识库人工复核关键内容批量任务中途卡住其中一个文件异常阻塞看日志找到卡住的文件给每个任务加超时和异常捕获GPU 显存不足模型过大或并发过高观察 nvidia-smi降低 batch_size换量化模型减少上下文端口被占用本地服务冲突lsof -i:8000或netstat -ano换端口或杀掉旧进程自动发送导致误发流程缺少人工审批检查代码中的发送逻辑先输出草稿人工确认后再发送输出质量不稳定提示词指令不清晰多次测试同一提示词固定 few-shot 示例降低 temperatureAI 幻觉是整个排查表里最值得注意的一项。工作流里只要有“自动把结果写进邮件/文档/工单”的环节就必须加一层校验让模型先输出可解析的数据再写一份人工可读摘要最后由人按下发送键。9. 给技术人的务实建议把 AI 改造成同事而不是对手看完这整条链路你应该已经意识到真正复杂的工作不是“让 AI 说一句话”而是把“一句话”变成一个可靠的工作流。下面几条是我在做 AI 应用开发和模型部署时的通用原则建议直接收藏。9.1 先跑最小闭环不要一上来就设计十个 Agent 的编排系统。先做单 Agent 单脚本 单文件夹跑通一个真实的日常任务。比如把“整理今日待办”做成脚本核心代码不超过 50 行。跑通之后再加定时触发、加队列、加多工具调用。9.2 输入、输出、日志分目录管理project/ ├── notes/ # 原始输入 ├── drafts/ # 生成结果 ├── logs/ # 运行日志 ├── config.json # 配置文件 └── scripts/ # 脚本目录这个结构适用于绝大多数自动化任务方便排查问题也方便后续接入 CI/CD 或定时任务。9.3 给关键流程加熔断如果 AI 连续失败 N 次应该停止批量调用而不是继续把错误结果写进文件。最简单的做法是在脚本里记一个失败计数器超过阈值就发一封告警邮件或打印明显错误。9.4 用好 AI 编程节省重复劳动与其担心“AI 取代编程”不如先把 AI 编程当作重构重复劳动的杠杆。通用代码模板、正则表达式、SQL 查询、配置脚本这类任务交给 AI 写了之后做 code review你会发现自己的注意力能更好地放在架构和边界设计上。9.5 明确人机分工所有 AI 自动化系统都建议遵守一个原则AI 生成内容人来做决策和发布。也就是说输出存在drafts/和输出直接发到公司群是两套完全不同的系统。前者是效率工具后者是风险敞口。10. 总结与下一步回到标题一个 POV 视频说“AI 今天早上取代了我的工作”。看完上面的技术拆解你应该能得出自己的结论AI 能取代的不是“你”而是“信息在工具间搬运”这个环节。真正的工作不会消失但工作流一定会被重新设计。对你来说最值得现在做的事很简单找一个小而重复的任务用文中第一节的能力拆解方法判断它属于哪一类然后照着第二节到第六节的环境准备、代码启动、功能测试和批量任务方案搭一个最小可运行版本。先验证输出格式再验证批量稳定性最后再考虑是否接入真实业务。最容易踩的坑有两个一是跳过人工审批直接全自动发布二是一开始就想做多 Agent 大系统。避开这两点AI 自动化工作流大概率能帮你省下不少重复劳动时间。如果你已经开始搭自己的第一套 Agent 工作流建议收藏这篇文章把环境准备清单、批量任务脚本和排查表复制下来跑完一个任务再回头看会发现很多细节只有在真机测试里才能暴露出来。