1. 为什么说“普通人第一个 Agent 不要从工具开始”是句大实话

最近在几个技术社群里，几乎每天都能看到类似的问题：“想学 Agent，该先装 Ollama 还是直接上 LangChain？”、“有没有一键部署的开源 Agent 框架推荐？”、“我用 AutoGen 写了个股票提醒 bot，但调用飞书 API 总报错，是不是模型太小了？”——这些问题背后，藏着一个被严重低估的认知断层：绝大多数人根本没搞清楚自己到底在构建什么，就急着去拧螺丝、焊电路、刷固件。

“普通人的第一个 Agent”这个说法本身就带着强烈的现实锚点——它不是实验室里的 demo，不是大厂内部的 MLOps 流水线，更不是论文里那个带 17 个模块、3 层反思循环、附带数学证明的“理想 Agent”。它是你早上通勤路上用语音问“今天会议几点？会议室订好了吗？”，手机自动查日历、翻钉钉群公告、再给你弹出一条带确认按钮的卡片；是你写周报卡壳时，把上周零散的会议纪要、Git 提交记录、Jira 工单截图扔进一个框，它帮你理出三条核心进展和两个待跟进风险；甚至是你妈发来一张模糊的药盒照片，问“这药能和降压药一起吃吗？”，你转发给它，它比你更快翻出说明书第 4 页的禁忌说明。这些场景里，Agent 的价值不在于它用了多少 token、调了几轮 LLM、是否支持 function calling，而在于它是否真的替你省下了那 8 分钟、避免了那一次误操作、接住了那个本该由你承担却差点漏掉的责任。

所以标题里那句“不要从工具开始”，本质是在喊停一种危险的惯性：我们太习惯把“技术栈”当成起点。就像教人做饭，没人会一上来就发一套德国双立人刀具+Molteni 烤箱+真空封口机，然后说“现在，你已经是主厨了”。可现实是，当“Agent”这个词刚火起来，社区文档、教程、开源项目全在疯狂堆砌工具链：LangChain 的 chain 太重？换 LlamaIndex；LlamaIndex 的 retriever 不够快？加 Weaviate；Weaviate 配置太复杂？上 ChromaDB；ChromaDB 嵌入效果差？换 BGE-M3 模型……一圈折腾下来，人还在环境配置里打转，连“我的 Agent 要解决什么问题”都没想明白。我见过最典型的案例，是一位做跨境电商的运营同学，花了三周时间配通了 AutoGen 的 group chat，能自动从 Shopify 后台拉订单、调用 OpenAI 解析客户差评情绪、再生成回复草稿——但他最后发现，90% 的差评其实就三类：“物流慢”、“货不对板”、“不会用”。他手写三个模板，用 Excel 的 VLOOKUP 就能覆盖 85% 场景，耗时 20 分钟。工具没毛病，错的是启动顺序。

真正属于普通人的 Agent，必须满足三个硬门槛：第一，问题定义足够窄——不是“帮我管理所有工作”，而是“每天上午 9 点前，把销售部昨日成交的 5 单客户信息（姓名、金额、产品型号）整理成表格发我邮箱”；第二，输入输出足够确定——输入是固定格式的 CRM 导出 CSV，输出是固定字段的 Excel，中间哪怕模型崩了三次，只要最终结果对，用户就认为它“能用”；第三，失败成本足够低——它出错，顶多让你多点一次鼠标重试，而不是删库跑路或发错客户隐私。这三个门槛，和你选的是 Ollama 还是 vLLM、用的是 JSON Schema 还是 XML、是否接入 RAG，半毛钱关系都没有。它们只和一件事有关：你有没有先把自己当成那个被服务的人，而不是那个写代码的人。

这也就是为什么，我坚持认为普通人的第一个 Agent，应该诞生于一个微信对话框、一个 Notion 页面、甚至是一张手写的便利贴。它的第一行代码，不该是pip install langchain，而应该是你用手机备忘录记下的：“老板总在周五下午 4 点催周报，我每次都赶在最后一刻写，容易漏掉关键数据。”——这句话，才是真正的 Agent 种子。工具只是后来长出来的枝干，根，永远扎在具体的人、具体的痛、具体的时间点里。

2. 普通人构建 Agent 的真实路径：从“人肉流程”到“最小闭环”

2.1 先别碰代码：用纸笔拆解你的“人肉 Agent”流程

很多人一听“构建 Agent”，下意识就打开 VS Code，这恰恰是最大的陷阱。真正的起点，是你每天重复做的、那些让你觉得“烦但又不得不做”的事。比如我辅导过的一位 HR 同学，她的痛点是“新员工入职材料收集总拖进度”。我们没聊任何技术，而是拿出一张 A4 纸，分三栏画了个表：左边写“我实际怎么做”，中间写“为什么非得这么做”，右边写“卡点在哪”。

• 左边（动作）：

  • 周一上午发邮件给部门负责人，列 8 项材料清单；
  • 周三下午翻邮箱，把收到的 PDF/Word 附件下载到“入职材料_202406”文件夹；
  • 周四上午手动检查每份文件是否齐全（比如身份证正反面、离职证明、体检报告），缺的标红发微信催；
  • 周五下午把齐备的文件打包，发给法务同事审核。

• 中间（逻辑）：

  • 发邮件是因为系统没自动触发流程；
  • 下载到固定文件夹是为了避免找不着，但其实经常下错位置；
  • 手动检查是因为 PDF 里文字没法搜索，只能靠眼睛扫；
  • 打包发法务是因为没有权限直接推送到法务系统。

• 右边（卡点）：

  • 邮件常被淹没，负责人平均 2.3 天才回复；
  • 文件命名混乱，有“张三身份证.jpg”“李四-身份证扫描件.pdf”，导致检查时反复确认；
  • 体检报告格式不统一，有的医院盖章在首页，有的在末页，人工核对易漏；
  • 法务反馈“缺材料”后，微信催人效率低，对方常回“稍等，我找找”，结果三天没下文。

这张纸的价值，远超任何框架文档。它逼你直面一个事实：你所谓的“自动化需求”，90% 的障碍不在技术侧，而在业务侧的模糊、规则的缺失、责任的错位。当你发现“体检报告盖章位置不统一”是核心卡点，解决方案可能根本不是写个 OCR 模型去定位印章，而是推动公司统一要求所有合作医院使用标准模板——这才是真正的 Agent 设计思维：先改流程，再用技术加固。

提示：这个阶段严禁引入任何工具。如果忍不住想打开 Notion 建数据库，立刻停下，问自己：“这张纸上的哪一步，是我今天下班前就能用手写方式优化的？” 比如，把邮件清单改成带勾选框的 PDF 表格，让负责人直接打印签字扫描回传，至少能把“邮件淹没”问题降低 60%。这就是最小改进，也是 Agent 的雏形。

2.2 定义“最小可行 Agent”：三个不可妥协的硬指标

基于纸笔拆解，下一步是提炼出你的 Agent 必须达成的“最小闭环”。它不追求酷炫，只保证在真实场景中“不掉链子”。我给自己定过三条铁律，至今没改过：

第一，输入必须“傻瓜式”可交付。
你的 Agent 不能要求用户提供结构化数据。它得能处理微信里糊成一团的截图、Excel 里合并单元格的乱码、甚至语音转文字后满屏的“呃”“啊”“那个”。比如那位 HR 同学，她最初的 Agent 输入，就是把所有材料一股脑拖进一个微信对话框（她建了个专用小号），而不是要求各部门按“姓名_材料类型_日期”重命名。这意味着，Agent 的第一道工序必须是鲁棒的文件解析——不是用 fancy 的多模态模型，而是先写个 Python 脚本，用pdfplumber提取 PDF 文字，用python-docx读 Word，对图片用pytesseractOCR，再用正则匹配关键字段（如“身份证号码：[0-9X]{18}”）。重点不是精度多高，而是“有总比没有强”。我实测过，哪怕 OCR 准确率只有 70%，配合人工二次确认，也比纯手动快 3 倍。

第二，输出必须“零理解成本”。
用户不需要看日志、不需要查文档、不需要猜状态。结果要么是“✅ 全部齐备，已打包发送法务”，要么是“❌ 缺张三的离职证明（联系人：王经理 138****1234），点击此处一键微信催办”。这里的关键是“一键催办”——不是生成一段话让你复制粘贴，而是直接调用微信 PC 版的wxauto库，自动打开聊天窗口、粘贴预设文案、回车发送。很多教程教你用 Webhook 接入企业微信，但普通人哪有权限申请？wxauto是绕过所有审批的野路子，它不优雅，但有效。我见过最绝的案例，是位老师用它自动批改选择题：学生拍照上传答题卡，Agent OCR 识别选项，比对答案库，生成带红叉/对勾的 PDF，再用微信直接发回学生——整个过程，老师只做了两件事：拍张照，点个发送。

第三，失败必须“可追溯、可干预”。
任何 Agent 都会出错，关键是如何让用户快速接管。我的做法是：每次运行后，自动生成一份run_log_20240615_142301.json，里面记录每一步的输入、输出、耗时、错误堆栈。更重要的是，这个日志文件本身就是一个“干预入口”——比如 OCR 识别身份证号失败，日志里会写"step": "ocr_id_card", "input_file": "zhangsan_id.jpg", "error": "no text detected"，然后 Agent 会自动在微信里发：“张三的身份证图片识别失败，请重新发送清晰正面照（建议白底、无反光）”。用户发新图，Agent 就自动续跑后续步骤。这种设计，把“调试”变成了“用户协作”，而不是开发者独自面对黑屏日志。

注意：这三条指标，和你用不用 LangChain、是否支持流式输出、能不能调用 100 个工具，完全无关。它们只回答一个问题：“当用户第一次用它时，会不会在 30 秒内明白它能做什么、不能做什么、出错了怎么办？” 如果答案是否定的，所有技术投入都是沉没成本。

2.3 工具选型的底层逻辑：为什么 Ollama 和 LangChain 反而是“高级玩具”

现在回到标题里那个刺眼的词：“不要从工具开始”。这不是贬低工具，而是划清主次。Ollama、LangChain、LlamaIndex 这些，本质上是“乐高积木”，但普通人拿到积木的第一反应，不该是研究“这块蓝色的 2x4 颗粒和那块红色的 1x6 颗粒如何咬合”，而该问：“我想搭的，到底是个能跑的小车，还是个会发光的城堡？”

以 Ollama 为例，它确实让本地跑 LLM 变得极简，ollama run qwen:7b一行命令就搞定。但问题来了：你的 Agent 真的需要“本地跑 7B 模型”吗？那位 HR 同学的材料核验，核心是规则匹配（身份证号长度、离职证明落款日期是否早于入职日），用正则和dateutil库就能覆盖 95% 场景。剩下 5%，比如识别手写签名是否与身份证一致，这才需要图像比对模型——但此时，直接调用百度 AI 开放平台的idcard_ocr接口，准确率 99.2%，响应 300ms，还送免费额度。你花三天配通 Ollama 的 GPU 加速，不如花 30 分钟注册个百度账号。

LangChain 更典型。它的Chain抽象很美，SequentialChain、TransformChain、RouterChain听起来像交响乐团指挥。但现实是，你的第一个 Agent 很可能只需要一个if-else：

if material_type == "id_card": result = ocr_id_card(file_path) elif material_type == "resignation": result = extract_date_from_pdf(file_path, keyword="离职日期") else: result = "未知材料类型，请人工审核"

硬套 LangChain 的LLMChain，反而要写一堆PromptTemplate、OutputParser，最后发现result字段还得手动json.loads()——这哪是提效，这是给自己加戏。

我总结了一个工具决策树，普通人直接照搬就行：

1. 先问：这事人手动做，最耗时的环节是什么？

   • 如果是“找数据”（比如从 10 个不同系统里捞客户信息）→ 优先学pandas读 Excel/CSV，requests调 API，openpyxl写报表；
   • 如果是“判规则”（比如合同里某条款是否触发违约）→ 优先学正则、dateutil、pypdf提取文本；
   • 如果是“生成内容”（比如根据销售数据写周报摘要）→ 再考虑 LLM，且从最轻量的开始：先用dashscope的qwen-maxAPI（免部署、按 token 付费），跑通流程后再想本地化。

2. 再问：这个环节，有没有现成的、不用代码就能解决的方案？

   • 微信自动回复？用“微信 PC 版 + wxauto”；
   • 邮件自动归档？用 Outlook 规则或 Gmail Filter；
   • 表格数据联动？用 Notion 的 Relation + Rollup，或 Airtable 的 Automations。

3. 最后问：如果真要写代码，它是否满足“单文件、少依赖、易调试”？

   • 我的 Agent 主程序，永远是一个main.py，依赖不超过 5 个 pip 包，print()日志打满屏幕，出错直接traceback.print_exc()。绝不为了“架构漂亮”拆成 10 个模块，最后调试时在 import 链里迷路。

工具不是目的，是杠杆。杠杆的支点，永远是你对问题本质的理解深度。没找准支点，再长的杠杆也撬不动一克重量。

3. 实操落地：从零搭建一个“周报生成 Agent”的完整过程

3.1 需求再聚焦：砍掉所有“看起来很美”的功能

我们以“周报生成 Agent”为实战案例。网上太多教程一上来就讲“用 LangChain 构建多智能体协作，自动分析 Git 提交、Jira 工单、会议纪要，生成 PPT 和 PDF”，听着热血，落地即死。真实世界里，一位普通产品经理的周报，核心就三件事：

• 数据源固定：每周五下午 5 点，市场部发来weekly_data_20240614.xlsx（含新增用户数、渠道 ROI）；研发部发来jira_summary_20240614.md（含本周完成的 3 个 Story 和 2 个 Bug）；我自己记的meeting_notes.txt（含与 CEO 的 1v1 关键结论）；
• 格式固定：公司模板要求分三块：“本周进展”（bullet point）、“下周计划”（bullet point）、“风险与求助”（最多 2 条）；
• 交付固定：邮件发给直属领导，主题为“【周报】张三_20240607-0614”，正文是纯文本，附件是 PDF。

所以，我们的 Agent 目标极度明确：在每周五下午 5:01，自动合并三份文件，按模板填空，生成邮件并发送。其他所有功能——比如自动抓取 Jira 数据（需 API Token）、分析用户增长趋势（需 Pandas 绘图）、生成 PPT（需 python-pptx）——全部砍掉。记住，第一个 Agent 的使命不是“全能”，而是“可靠”。

实操心得：我曾帮一位设计师同学做“海报生成 Agent”，她最初需求是“输入文案，自动排版、选图、配色、生成 PNG”。我们硬着头皮做了两周，卡在字体版权和图片商用授权上。最后砍到只剩“输入文案，用 Canva 模板 ID + API 自动填充文字，生成链接”，3 小时搞定。她现在每周用它生成 20 张活动海报，稳定运行 5 个月零故障。减法，才是普通人的第一生产力。

3.2 核心环节实现：用最朴素的代码，解决最具体的痛点

步骤 1：统一数据入口——微信小号 + wxauto 监听

不折腾企业微信审批，不搞邮箱规则过滤，就用个人微信。新建一个微信号（昵称“周报小助手”），加进所有相关同事的企业微信（微信和企微互通）。用wxauto监听消息：

from wxauto import WeChat import time import os wx = WeChat() # 监听指定群聊（如“产品周报数据组”） while True: msgs = wx.GetLastMessage(n=10) # 获取最近 10 条 for msg in msgs: if "weekly_data" in msg.text and msg.file_path: # 下载 Excel 文件，重命名为固定名 new_path = os.path.join("data", "weekly_data.xlsx") os.rename(msg.file_path, new_path) print(f"✅ 已接收市场数据：{new_path}") elif "jira_summary" in msg.text and msg.file_path: new_path = os.path.join("data", "jira_summary.md") os.rename(msg.file_path, new_path) print(f"✅ 已接收研发数据：{new_path}") time.sleep(60) # 每分钟检查一次

这段代码的精妙之处，在于它用“文件名关键词”代替了复杂的 NLP 分类。同事发文件时，只要文件名带weekly_data，Agent 就认出是市场数据——简单、鲁棒、零训练成本。

步骤 2：结构化解析——用正则和 Pandas 做“数字翻译官”

weekly_data.xlsx是标准表格，但列名可能五花八门：“新增用户数”、“New Users”、“本周新增”。我们不追求通用解析，只针对这份文件写死规则：

import pandas as pd import re def parse_market_data(): df = pd.read_excel("data/weekly_data.xlsx") # 直接取第一行作为列名（假设格式固定） cols = df.iloc[0].tolist() data = df.iloc[1:].values.tolist()[0] # 取第二行数据 # 用正则从列名中提取关键指标 user_col = [c for c in cols if re.search(r"(新增|new).*用户", str(c), re.I)] roi_col = [c for c in cols if re.search(r"(roi|投资回报)", str(c), re.I)] return { "new_users": int(data[cols.index(user_col[0])]) if user_col else 0, "channel_roi": f"{data[cols.index(roi_col[0])]:.1f}%" if roi_col else "N/A" } # 解析结果示例：{"new_users": 1250, "channel_roi": "23.5%"}

同样，jira_summary.md是 Markdown，但内容固定：

## 本周完成 - Story: 用户登录页增加指纹识别（ID: PROD-123） - Bug: 修复 iOS 17 下支付失败（ID: BUG-456） ## 待办 - Story: 订单导出功能（预计下周上线）

解析脚本只需两行正则：

with open("data/jira_summary.md") as f: text = f.read() done_stories = re.findall(r"- Story: (.*?)(?=\n|$)", text.split("## 本周完成")[1]) bugs = re.findall(r"- Bug: (.*?)(?=\n|$)", text.split("## 本周完成")[1]) # 结果：done_stories = ["用户登录页增加指纹识别（ID: PROD-123）"]

这种“面向具体文件”的硬编码，看似不优雅，却是普通人最稳的路径。它不依赖模型泛化能力，不担心 prompt 漂移，只要文件格式不变，它就永远精准。

步骤 3：模板填充与邮件发送——用字符串格式化，拒绝过度设计

周报模板是纯文本，我们用 Python 的str.format()：

template = """【周报】张三_{start_date}-{end_date} ## 本周进展 - 市场：新增用户 {new_users} 人，渠道 ROI {channel_roi} - 研发：完成 {story_count} 个 Story，修复 {bug_count} 个 Bug {stories_list} {bugs_list} ## 下周计划 - Story: 订单导出功能上线（PROD-789） - Bug: 优化安卓端启动速度 ## 风险与求助 - 需要设计部提供新版图标（截止：6月21日） """ # 填充数据 report_text = template.format( start_date="20240607", end_date="20240614", new_users=parsed_data["new_users"], channel_roi=parsed_data["channel_roi"], story_count=len(done_stories), bug_count=len(bugs), stories_list="\n ".join([f"- {s}" for s in done_stories]), bugs_list="\n ".join([f"- {b}" for b in bugs]) ) # 发送邮件（用 yagmail，一行代码搞定） import yagmail yag = yagmail.SMTP("your_email@company.com", "app_password") yag.send( to="boss@company.com", subject=f"【周报】张三_20240607-0614", contents=report_text )

全程没有 LLM，没有向量库，没有 RAG。它就是一个“数据搬运工”，把 Excel 里的数字、Markdown 里的文字，精准地塞进模板的坑里。但正是这种极致的简单，让它在生产环境里跑得比任何“智能 Agent”都稳。

3.3 部署与守护：让 Agent 真正“活”在你的工作流里

写完代码不等于结束。真正的挑战是：如何让它每周五下午 5:01 准时开工，且出错时你能第一时间知道？

方案一：Windows 任务计划程序（最推荐给新手）

• 新建基本任务 → 触发器设为“每周五，下午 5:01”；
• 操作设为“启动程序”，程序为python.exe，参数为"C:\path\to\main.py"；
• 在“常规”选项卡勾选“不管用户是否登录都要运行”，并设置“只在计算机使用交流电源时运行”（防笔记本休眠中断）。

方案二：Linux crontab（适合有服务器的同学）

# 编辑 crontab crontab -e # 添加这一行（每周五 17:01 执行） 1 17 * * 5 cd /home/user/weekly_agent && /usr/bin/python3 main.py >> /home/user/weekly_agent/log.txt 2>&1

关键守护机制：心跳检测与告警
光靠定时任务不够。万一周五下午电脑关机了呢？或者main.py运行中报错退出了呢？我们加一层保险：

# 在 main.py 结尾添加 import smtplib from email.mime.text import MIMEText def send_alert(subject, body): msg = MIMEText(body) msg['Subject'] = subject msg['From'] = "alert@company.com" msg['To'] = "your_email@company.com" # 发送逻辑（略） try: # 主流程执行... print("✅ 周报生成成功！") except Exception as e: send_alert("⚠️ 周报 Agent 执行失败", f"错误：{e}\n时间：{time.ctime()}") raise

这样，只要 Agent 挂了，你的手机就会收到邮件告警。我甚至把它和微信打通：用yagmail发邮件到自己的 QQ 邮箱，QQ 邮箱设置“微信通知”，5 秒内手机震动——这才是普通人能掌控的“可观测性”。

注意事项：所有路径（如data/文件夹、日志文件）必须用绝对路径，否则定时任务执行时会找不到目录。我在 Windows 上吃过亏：任务计划程序默认工作目录是C:\Windows\System32，open("data/file.xlsx")直接报错。解决方案：在main.py开头加os.chdir(os.path.dirname(os.path.abspath(__file__)))，强制切换到脚本所在目录。

4. 常见问题与排查技巧实录：那些没人告诉你的坑

4.1 “文件接收不到”问题：微信协议限制与绕过方案

现象：wxauto监听不到同事发来的文件，或者只收到文件名，收不到实际文件。

根本原因：微信 PC 版的协议限制。当文件大于 100MB，或发送方用的是手机版微信（尤其 iOS），PC 端可能只同步消息文本，不下载文件。这不是代码 bug，是微信的“防盗”机制。

实测有效的三种绕过方案：

1. 强制“下载原图/原文件”：在微信 PC 版设置中，关闭“自动下载图片、视频和文件”，改为“仅在 Wi-Fi 下下载”。然后让同事发文件时，长按文件 → 选择“下载原文件”。实测成功率 95%。
2. 用“文件传输助手”中转：让同事先把文件发到“文件传输助手”，再从“文件传输助手”转发到你的监听群。因为“文件传输助手”是微信官方账号，协议兼容性最好。
3. 终极方案：换钉钉。如果团队允许，直接迁移到钉钉。dingtalk的 Python SDK 对文件上传/下载支持极好，且无大小限制。我帮一家公司迁移后，文件接收失败率从 30% 降到 0.2%。

排查技巧：在wxauto代码里加一句print(f"收到消息：{msg.text}, 文件路径：{msg.file_path}")，运行时观察控制台输出。如果file_path是None，说明微信根本没把文件同步过来，这时候别 debug 代码，直接换方案。

4.2 “OCR 识别不准”问题：不是模型不行，是预处理没做对

现象：用pytesseract识别身份证图片，结果全是乱码，或者把“1”识别成“l”。

真相：90% 的 OCR 失败，源于图像质量。Tesseract 不是魔法，它需要清晰、高对比度、文字水平的图像。

四步预处理法（亲测提升准确率 80%）：

1. 灰度化 + 二值化：

   from PIL import Image import cv2 import numpy as np img = cv2.imread("id.jpg", cv2.IMREAD_GRAYSCALE) # 自适应阈值二值化，比固定阈值更鲁棒 binary = cv2.adaptiveThreshold(img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 11, 2)

2. 去噪：用cv2.medianBlur(binary, 3)消除椒盐噪声。
3. 旋转校正：用cv2.minAreaRect()检测文字区域角度，cv2.warpAffine()旋转回正。
4. 放大：cv2.resize()放大 2 倍，让 Tesseract 有更多像素可分析。

处理后的图像再喂给pytesseract.image_to_string()，准确率从 40% 直奔 95%。记住，没有完美的 OCR 模型，只有完美的预处理流水线。

4.3 “邮件被当垃圾邮件”问题：发信域名与 SPF 记录

现象：用yagmail发的周报邮件，总出现在领导的“垃圾邮件”文件夹。

根源：企业邮箱对发信域名有严格验证。如果你用gmail.com账号发@company.com邮件，Gmail 服务器会伪造发件人，触发 SPF（Sender Policy Framework）检查失败。

解决方案（三选一）：

• 最优解：用公司邮箱 SMTP。联系 IT 部门，申请一个专用邮箱（如weekly-report@company.com）和 App Password，配置yagmail.SMTP("weekly-report@company.com", "app_pass")。SPF 记录公司已配好，100% 过滤。
• 次优解：用 Mailgun 或 SendGrid。注册免费账户，它们提供合规的发信域名和 API，集成yagmail只需改两行代码。
• 应急解：改邮件主题和内容。避免“自动”“机器人”“Report”等敏感词，主题用“张三_20240607-0614_工作汇总”，正文开头加一句“本邮件由张三手动整理，如有疑问请随时联系”。人类语言能骗过部分垃圾邮件算法。

实操心得：我曾因邮件被拒，连续两周周报没送达。最后发现，IT 部门给的 SMTP 端口是 587，我写成了 465。一个数字之差，浪费三天。所以，所有配置项，务必手敲，不要复制粘贴。把smtp.company.com:587写在便利贴上，贴在显示器边框。

4.4 “Agent 跑着跑着就停了”问题：进程守护与资源泄漏

现象：wxauto监听脚本运行几天后，微信 PC 版自动退出，或者 CPU 占用飙升到 100%。

核心原因：wxauto基于 Windows UI 自动化，长期运行会积累内存泄漏，且微信客户端自身不稳定。

双保险守护方案：

1. 进程级重启：用psutil检测微信进程是否存在，不存在则自动重启：

   import psutil import os import time def ensure_wechat_running(): wechat_procs = [p for p in psutil.process_iter() if "WeChat.exe" in p.name()] if not wechat_procs: print("⚠️ 微信已退出，正在重启...") os.startfile(r"C:\Program Files (x86)\Tencent\WeChat\WeChat.exe") time.sleep(10) # 等待启动

2. 脚本级重启：用supervisor（Linux）或NSSM（Windows）将main.py注册为服务，崩溃后自动拉起。Windows 上，NSSM配置最简单：下载 nssm.exe，命令行执行nssm install WeeklyAgent，在 GUI 里填入脚本路径，勾选“自动重启服务”。

终极提示：所有长期运行的 Agent，必须有“心跳日志”。我在main.py里加了一行：

with open("heartbeat.log", "a") as f: f.write(f"{time.ctime()} - Alive\n")

然后用 Windows 计划任务，每天凌晨 3 点检查heartbeat.log最后一行时间。如果超过 2 小时没更新，就发邮件告警。这比任何监控平台都直接有效。

5. 从“第一个 Agent”到“可持续进化”的认知跃迁

做完上面所有，你已经拥有了一个真正可用的 Agent。但它不该是终点，而应成为你理解“人机协作”本质的起点。我观察过上百个普通人的 Agent 实践，发现一个关键分水岭：能否把 Agent 从“工具”升维成“工作伙伴”，取决于你是否愿意持续迭代它的“人格”与“边界”。

所谓“人格”，不是给它起名字、加表情包，而是赋予它符合你工作风格的交互逻辑。比如，那位 HR 同学的 Agent，最初只会冷冰冰说“缺离职证明”。后来她加了一条规则：“如果催办超过 2 次，自动在微信里发‘王经理，打扰了，这个材料关系到张三下周入职，方便时麻烦您优先处理下，谢谢！’”。这句话里，“关系到下周入职”是事实，“麻烦您优先处理”是请求，“谢谢”是温度——它让 Agent 从“报警器”变成了“懂分寸的同事”。这种迭代，不靠模型微调，靠的是你对自己沟通习惯的诚实复刻。

所谓“边界”，则是清醒认知它的能力极限，并主动设计“人机交接点”。我的周报 Agent，永远在生成 PDF 后停住，不自动发送。为什么？因为 PDF 里可能有敏感数据（如未脱敏的客户手机号），必须由我肉眼确认。这个“停顿”，不是缺陷，而是信任的锚点。我甚至在 PDF 生成后，加了一行os.system("start report.pdf")，让 Windows 自动打开文件——我的手指悬在键盘上，盯着屏幕 3 秒，确认无误后，才按