API集成

从「你问它答」到「事件触发它干」 手动调 API 再进一步，是让大模型嵌入已有的信息流：新邮件进来自动摘要、表单提交后自动分类打标签、每天早八点自动汇总昨天的数据生成日报。这时大模型不再是一个对话框，而是流水线上的一个「处理节点」。要做到这一步，关键不是模型多强，而是搞清楚用什么触发它、结果往哪送。 两种触发方式 第一种是定时触发：到点自动跑，适合周期性任务。Linux 上用 crontab，Windows 用任务计划程序，本质就是定时执行你写的那个批处理脚本。比如每天 8 点跑一个脚本：拉取昨天的销售数据 → 拼成提示词 → 调本地或云端模型生成日报 → 把结果发到企业微信/飞书。crontab 里加一行 0 8 * * * /usr/bin/python3 /path/to/daily_report.py 就成。 第二种是事件触发（Webhook）：某个动作发生时，外部系统主动推一个请求过来，你的服务接住、调模型、返回结果。典型场景：客服系统收到新工单，Webhook 推给你的服务，服务调模型自动打标签并建议回复，再写回工单系统。这时你需要一个常驻的小服务（FastAPI 几十行就够）监听一个端口： from fastapi import FastAPI, Request app = FastAPI() @app.post("/new-ticket") async def handle(req: Request): data = await req.json() # 这里调模型对 data["content"] 打标签 label = call_llm_to_label(data["content"]) return {"label": label} 触发方式 适合任务 部署形态 定时任务 日报、周报、周期汇总 crontab 跑脚本 Webhook 新消息、新工单、表单提交 常驻小服务监听端口 三个集成要点 第一，结果要有地方落：模型生成的日报要发到哪、打的标签要写回哪，提前想好——飞书/企业微信群机器人 webhook、数据库、工单系统 API，都是常见的「出口」。第二，给 AI 留人工兜底：自动打标签、自动回复这种事，别让它直接对外发，先存草稿或进待审队列，人工确认再发，避免一条错误回复发给客户。第三，本地模型还是云端：定时跑、对延迟不敏感的日报，用本地 Ollama 省钱；Webhook 高并发、要快的，用云端 API。按场景选，别一刀切。 收束 大模型的真正杠杆，不在「它答得多好」，而在「它嵌进了多少信息流」。定时任务让它成为你的自动播报员，Webhook 让它成为你业务系统里随时待命的处理节点。一旦它从被动问答变成随事件自动干活，你的时间就被真正解放出来——这才是 AI 自动化的全貌。 去论坛讨论 关于「AI自动化」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

手动调 API 的隐性成本 你有一份 Excel 里 500 条产品标题要写卖点、或者 300 条客服对话要打标签，手动在对话框里一条条复制粘贴，一下午就没了，还容易漏。这件事的正解是写个批处理脚本：读入数据 → 逐条调 API → 把结果写回 CSV。看起来简单，但生产里真正费时间的是三个问题：断了怎么办、失败怎么办、速度慢怎么办。把这三件事想清楚，脚本才真正好用。 一个最小可用模板 核心结构是：读 CSV、循环调 API、写回结果。先把骨架搭起来： import csv, time from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") with open("input.csv", newline="", encoding="utf-8") as f: rows = list(csv.DictReader(f)) for i, row in enumerate(rows): if row.get("done") == "yes": continue # 断点续跑：跳过已处理的 try: resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": f"给这句写卖点：{row['title']}"}], temperature=0.3 ) row["output"] = resp.choices[0].message.content row["done"] = "yes" except Exception as e: row["output"] = f"ERROR: {e}" time.sleep(5) # 出错退避 # 每处理一条就落盘，防止中途崩了全丢 with open("output.csv", "w", newline="", encoding="utf-8") as f: w = csv.DictWriter(f, fieldnames=rows[0].keys()) w.writeheader(); w.writerows(rows) 这个模板里藏着三个关键设计。 三个让脚本变可靠的设计 第一，断点续跑：输出文件里加一个 done 标记，每次启动先跳过已完成的。这样跑到 300 条崩了，重跑接着来，不用从头再来。第二，逐条落盘：每处理一条就把整份结果写回 CSV，而不是内存里攒到最后一次性写。中途断电、报错，损失的最多是当前那一条。第三，错误退避：API 调用包 try/except，失败时 sleep 几秒再继续，别因为一条失败让整个批次中断——失败的记成 ERROR，最后人工补。 问题 裸脚本 可靠脚本 中途崩溃 全丢，重跑 断点续跑，接着来 单条失败 整个循环停 记录错误，继续跑 想加速 串行一条条 加并发（见下） 再快一点：并发 串行调 500 条可能要半小时，用 concurrent.futures.ThreadPoolExecutor 开 5-10 个并发线程，能压到几分钟。但注意：并发数别开太高，云端 API 有 RPM（每分钟请求数）限速，开太高直接被限流封号；本地模型则受显存和并发 KV 限制，Ollama 默认并发能力有限，3-5 路就差不多了。开并发前先想清楚你的后端扛不扛得住。 ...