如何用 AI Agent Harness Engineering 自动化处理 Excel 和 CSV 数据

---

引言

核心概念

在正式展开之前，我们必须先拆解本文最核心的三个交叉技术栈词汇——这些词汇并非教科书里的标准术语（至少目前还没有被 IEEE/ACM 等组织统一收录为软件工程一级/二级学科术语），但它们是当前大语言模型应用开发、低代码/无代码自动化、数据处理工具链整合领域最前沿、最具落地性的组合词：

1.1.1 AI Agent（大语言模型驱动的智能代理）

AI Agent 是 2023 年以来 OpenAI 推出 GPT-4 Turbo + Function Calling、Anthropic 推出 Claude 3 Opus/Sonnet/Haiku + Tool Use 后，在技术圈和商业圈都爆火的概念。从本质上讲，AI Agent 是一个能够感知环境、生成目标、规划任务、执行工具、记忆状态、反思调整的自主/半自主智能体——它的核心不是“代码堆代码实现特定逻辑”，而是“用自然语言描述任务后，Agent 自己调用工具链完成目标，甚至还能自己排查报错、优化流程”。

在数据处理场景下，AI Agent 的「感知环境」就是读取 Excel/CSV 的元数据（表头、数据类型、行数/列数、缺失值分布、重复率、数据质量问题提示等）和结构化/半结构化数据；「生成目标」就是理解用户自然语言输入的“数据清洗规则、分析需求、可视化输出要求、自动化任务调度触发条件”等模糊指令，拆解成可量化的子目标；「规划任务」就是把拆解后的子目标映射到合适的工具（比如 Pandas、Polars、OpenPyXL、XlsxWriter、DuckDB、甚至是 Tableau Public/Power Automate 桌面版的 API）；「执行工具」就是调用 Function Calling/Tool Use 机制触发工具链的执行，中间还能处理参数验证、报错处理的子流程；「记忆状态」就是保存整个任务执行过程中的上下文（比如清洗后的中间数据、之前尝试失败的工具调用组合、用户之前纠正的错误假设），避免重复劳动或偏离目标；「反思调整」就是在任务执行失败或结果不符合预期时，自动调用反思逻辑（比如 GPT-4 Turbo 自带的 Chain-of-Thought（CoT）推理、更高级的 Self-Refine、Tree-of-Thought（ToT）推理），分析失败原因或偏差点，重新生成子目标和任务规划。

1.1.2 Harness Engineering（工程化 harness 框架搭建）

“Harness” 这个词在英文里的原意是“马具、挽具、安全带”——引申到软件开发和自动化领域，就是“把分散的工具、组件、API 用一套统一的框架、规范、接口串起来，形成一个稳定、可复用、可扩展、易调试的‘自动化系统骨架’”。在很多国内的技术分享里，这个词有时候也被翻译为“ harness 框架工程化”或者“自动化 harness 工程”——但不管翻译如何，它的核心都在于“标准化流程、模块化组件、容错机制完善、可观测性强、支持版本控制”这几个关键点。

之前，我们要搭建一套 Excel/CSV 数据处理的 harness 框架，往往需要自己从零写代码：比如用 argparse 或 click 处理命令行参数，用 logging 模块写日志，用 pytest 写单元测试，用 Airflow/Kestra/Cron 做任务调度，用 Docker 做环境隔离，用 Flask/FastAPI 做简单的 API 包装……整个过程不仅耗时耗力（对于新手来说可能需要几周甚至几个月才能搭建出一套能用的框架），而且很容易出现“代码耦合度高、修改一个地方牵一发而动全身、容错机制不全容易崩、日志太少/太乱不好排查问题、环境不一致导致的‘我本地跑得通，服务器跑不通’”等软件工程领域的经典问题。

1.1.3 AI Agent Harness Engineering（面向数据处理的 AI Agent 工程化 harness 框架搭建与实践）

把前面两个核心概念结合起来，就是本文的主题——AI Agent Harness Engineering（面向数据处理场景）：它不是“随便拿几个开源 Agent 框架（比如 LangChain、AutoGPT、AutoGen、CrewAI、AgentScope）随便拼几个 Excel/CSV 处理工具就能用的‘玩具项目’”，而是“用 Harness Engineering 的思路，搭建一套专门针对 Excel/CSV 数据处理场景的、符合软件工程最佳实践的 AI Agent 框架，并且通过大量的实际场景案例验证其稳定性、可复用性、可扩展性、易用性”。

具体来说，面向数据处理的 AI Agent Harness Engineering 应该包含以下几个核心要素（后面的章节会详细展开每个要素的定义、作用、实现方式、最佳实践）：

1. 统一的任务描述语言（TDL，Task Description Language）：虽然 AI Agent 主要是用自然语言交互，但为了提高任务的可复用性、可量化性、可调度性，我们需要一套简单的、基于自然语言扩展的结构化 TDL——比如可以把 TDL 定义为 YAML/JSON 格式的配置文件，里面包含“任务名称、任务描述（自然语言）、输入数据源路径、输出结果路径、数据质量检查规则（可选）、中间数据缓存策略（可选）、任务调度触发条件（可选）、用户反馈阈值（可选）”等字段；
2. 模块化的工具链整合系统：这里的工具链包括“Excel/CSV 读取/写入工具（Pandas、Polars、OpenPyXL、XlsxWriter、csvkit、DuckDB）、数据质量检查工具（Great Expectations、Pandera、Deequ）、数据分析工具（Pandas Profiling、SweetViz、D-Tale、PyCaret）、数据可视化工具（Matplotlib、Seaborn、Plotly、Altair）、自动化调度工具（Airflow、Kestra、Prefect、Cron）、错误监控与告警工具（Sentry、Prometheus + Grafana、钉钉/企业微信机器人）、环境隔离工具（Docker、Poetry、Pipenv、Conda）”等——每个工具都要被封装成一个独立的、符合统一接口规范的“工具函数（Tool Function）”或“工具类（Tool Class）”，方便 Agent 调用和替换；
3. 完善的记忆系统（Memory System）：记忆系统是 AI Agent 区别于普通 LLM + Function Calling 的核心之一——它应该包含“短期记忆（Short-Term Memory，STM）”（保存当前任务执行过程中的上下文，比如中间数据的位置、之前尝试失败的工具调用组合、用户刚刚纠正的错误假设，STM 可以用 Redis、内存中的字典/列表、或者 LangChain 的 ConversationBufferMemory 等实现）、“长期记忆（Long-Term Memory，LTM）”（保存历史任务的 TDL、执行过程、执行结果、用户反馈，LTM 可以用 PostgreSQL、MongoDB、向量数据库（比如 ChromaDB、Pinecone、Weaviate、Milvus）等实现，向量数据库主要用于“相似任务检索”，帮助 Agent 快速找到历史上处理过的类似任务，复用之前的 TDL 和任务规划）、“工具记忆（Tool Memory）”（保存每个工具函数的详细文档、参数说明、使用示例、历史调用记录、成功率、平均执行时间，工具记忆可以用 JSON/YAML 配置文件、或者数据库实现，向量数据库也可以用于“相似工具检索”，帮助 Agent 在多个功能类似的工具中选择最合适的一个）；
4. 强大的推理与反思系统（Reasoning & Reflection System）：推理系统帮助 Agent 理解用户的自然语言输入，生成子目标和任务规划；反思系统帮助 Agent 在任务执行失败或结果不符合预期时，分析原因并重新调整——推理系统可以用“Chain-of-Thought（CoT）、Tree-of-Thought（ToT）、Graph-of-Thought（GoT）、ReAct（Reasoning + Acting）、Reflexion（推理 + 反思 + 修正）”等先进的 LLM 推理技术实现；反思系统可以用“Self-Refine、Multi-Agent Debate（多智能体辩论）、Human-in-the-Loop（HITL，人在回路）反馈机制”等实现；
5. 可观测性与可调试性系统（Observability & Debugging System）：可观测性与可调试性是 Harness Engineering 必须要关注的核心点——对于 AI Agent 来说，可观测性系统应该包含“日志系统（Logging System）”（记录任务的整个执行过程，包括用户输入、Agent 推理过程、工具调用参数、工具执行结果、工具执行时间、工具执行状态、Agent 反思过程、最终输出结果等，日志系统可以用 Python 的 logging 模块、或者 LangSmith、LangFuse 等专门的 LLM 应用可观测性平台实现）、“监控系统（Monitoring System）”（监控 Agent 的执行状态、成功率、平均执行时间、工具调用频率、API 调用成本等，监控系统可以用 Prometheus + Grafana、或者 LangSmith、LangFuse 实现）、“告警系统（Alerting System）”（当 Agent 执行失败、成功率低于阈值、平均执行时间超过阈值、API 调用成本超过预算时，自动发送告警通知，告警系统可以用 Sentry、钉钉/企业微信机器人、或者 LangSmith、LangFuse 实现）、“调试面板（Debugging Dashboard）”（提供一个可视化的调试面板，让开发者可以实时查看任务的执行过程、修改 Agent 的推理过程、替换工具函数、调整参数等，调试面板可以用 LangSmith、LangFuse、或者自己用 Streamlit/Gradio 搭建实现）；
6. 易用性与可扩展性系统（Usability & Extensibility System）：易用性系统是为了让非技术人员（比如业务分析师、数据分析师助理、市场运营人员）也能使用这套 AI Agent 框架——它应该包含“自然语言交互界面（NLI，Natural Language Interface）”（可以用 Streamlit/Gradio 搭建一个 Web 界面，也可以用 Slack/Discord/钉钉/企业微信机器人搭建一个聊天界面，非技术人员只需要在界面上用自然语言输入任务即可）、“预定义任务模板库（Predefined Task Template Library）”（提供一套常见的 Excel/CSV 数据处理任务模板，比如“数据清洗（去重、填充缺失值、转换数据类型、删除异常值）、数据分析（描述性统计、相关性分析、分组聚合）、数据可视化（柱状图、折线图、饼图、散点图、热力图）、数据格式转换（Excel 转 CSV、CSV 转 Excel、Excel 转 JSON、CSV 转 Parquet）、数据合并（横向合并、纵向合并、按键合并）、数据拆分（按列拆分、按行拆分、按条件拆分）”等，非技术人员只需要选择模板、填写数据源路径和简单的参数即可）；可扩展性系统是为了让技术人员可以方便地添加新的工具函数、新的推理/反思技术、新的预定义任务模板——它应该包含“工具函数注册接口（Tool Function Registration Interface）”（技术人员只需要按照统一的接口规范编写工具函数，然后用装饰器或配置文件注册即可）、“推理/反思技术插件接口（Reasoning & Reflection Plugin Interface）”（技术人员只需要按照统一的接口规范编写推理/反思插件，然后用装饰器或配置文件注册即可）、“预定义任务模板添加接口（Predefined Task Template Addition Interface）”（技术人员只需要按照统一的模板规范编写预定义任务模板，然后用 YAML/JSON 配置文件或数据库添加即可）。

问题背景

现在，我们已经了解了本文的核心概念，接下来我们来聊聊为什么我们需要用 AI Agent Harness Engineering 来自动化处理 Excel 和 CSV 数据——换句话说，就是“传统的 Excel/CSV 数据处理方法有哪些痛点？”

1.2.1 传统方法的三大类

在 AI Agent 出现之前，我们处理 Excel 和 CSV 数据主要有以下三大类方法：

1. 第一类：纯手工操作 Excel；
2. 第二类：用简单的脚本/低代码/无代码工具；
3. 第三类：用企业级的数据处理工具/平台。

接下来，我们分别来看看每一类方法的具体操作和痛点。

1.2.2 第一类：纯手工操作 Excel——效率极低、容易出错、难以复用、无法处理大规模数据

纯手工操作 Excel 是最古老、但至今仍然是很多非技术人员（甚至是一部分技术人员）最常用的数据处理方法——它的具体操作就是：打开 Excel 软件，导入 CSV 数据（如果是 Excel 文件就直接打开），然后用 Excel 的内置功能（比如筛选、排序、查找替换、数据透视表、VLOOKUP/HLOOKUP/XLOOKUP、公式、图表等）处理数据，最后保存结果。

这种方法的优点只有一个：入门门槛极低——几乎所有会用电脑的人都能学会基本的 Excel 操作（比如筛选、排序、简单的公式）。

但是，这种方法的缺点实在是太多了，我们可以把它们总结为以下五大痛点：

1.2.2.1 痛点一：效率极低

纯手工操作 Excel 的效率完全取决于数据量的大小和任务的复杂度——如果是处理几十行、几列的简单数据（比如“统计一下公司员工的平均工资”），可能只需要几分钟；但如果是处理几万行、几十列的复杂数据（比如“从 10 个不同的 Excel/CSV 文件中按员工 ID 合并数据，去重，填充缺失的入职日期（根据身份证号前 6 位和第 7-14 位推导），删除工资低于当地最低工资标准或高于 CEO 工资 10 倍的异常值，按部门分组聚合计算平均工资、中位数工资、最高工资、最低工资、员工人数，生成每个部门的工资分布柱状图和饼图，最后把结果保存到一个新的 Excel 文件中，数据放在 Sheet1，图表放在 Sheet2，统计摘要放在 Sheet3”），可能需要几个小时甚至几天——而且中间不能出错，一旦出错就要从头再来。

更糟糕的是，纯手工操作 Excel 是线性的、不可并行的——你只能一个步骤一个步骤地做，不能同时处理多个步骤或多个文件；而且你必须一直盯着电脑屏幕，不能分心做其他事情。

1.2.2.2 痛点二：容易出错

纯手工操作 Excel 的出错率极高——据统计，全球范围内大约有88%的 Excel 文件存在错误，其中大约有1%的错误会导致严重的经济损失（比如英国巴林银行的倒闭、美国安然公司的财务造假、世界卫生组织在 COVID-19 疫情初期的数据统计错误等）。

纯手工操作 Excel 出错的原因主要有以下几个：

1. 人为操作失误：比如不小心按错了键盘上的某个键（比如 Delete 键删除了整列数据、Ctrl+Z 撤销了太多步骤）、不小心复制粘贴错了位置、不小心用错了公式（比如把 SUM 写成了 AVERAGE、把 VLOOKUP 的查找范围写少了一列、把 XLOOKUP 的匹配模式选错了）、不小心用错了数据透视表的字段（比如把“员工人数”放在了“值”字段的位置，却用了“求和”而不是“计数”）等；
2. 数据格式不一致：比如不同的 Excel/CSV 文件中，同一个字段的数据格式不一样（比如“入职日期”有的是“YYYY-MM-DD”格式的文本，有的是“MM/DD/YYYY”格式的文本，有的是“日期”类型的数据，有的是“数字”类型的数据——比如 Excel 把“2020-01-01”存储为数字 43831）；
3. 数据质量问题：比如 Excel/CSV 文件中存在大量的缺失值、重复值、异常值、拼写错误（比如“员工 ID”有的写成了“EmployeeID”、有的写成了“employee_id”、有的写成了“Employee ID”，甚至有的写成了“Employeee ID”）等——纯手工操作 Excel 很难发现所有的数据质量问题，更难批量处理；
4. Excel 软件的限制：比如 Excel 2007 及以后的版本最多只能处理1048576 行、16384 列的数据——如果数据量超过了这个限制，Excel 就会报错，甚至直接崩溃；再比如 Excel 的公式计算速度很慢——如果是处理几万行、几十列的数据，每个单元格都用了复杂的公式（比如嵌套了 VLOOKUP、IF、SUMIFS 等），Excel 可能需要几分钟甚至几十分钟才能计算完成，中间还可能会因为内存不足而崩溃。

1.2.2.3 痛点三：难以复用

纯手工操作 Excel 的可复用性极低——如果你今天处理了一个类似的任务，明天又要处理另一个类似的任务（只是数据源路径不一样、参数不一样），你仍然需要从头再来一遍所有的操作步骤——除非你用 Excel 的“宏（Macro）”功能录制操作步骤，但宏功能也有很多限制：

1. 宏只能录制操作步骤，不能录制逻辑判断：比如如果你在录制宏的时候，是“手动筛选出工资高于 10000 的员工”，那么宏就会把这个操作步骤录制下来——但如果明天的数据中，“工资高于 10000 的员工”变成了“工资高于 15000 的员工”，你就需要重新录制宏，或者手动修改宏的 VBA 代码（但 VBA 代码的入门门槛很高，很多非技术人员甚至技术人员都不会写）；
2. 宏的安全性很低：Excel 默认是禁用宏的——如果你要运行宏，必须先启用宏，而启用宏可能会导致电脑感染病毒或恶意软件（因为宏是用 VBA 代码编写的，VBA 代码可以访问电脑上的所有文件和系统资源）；
3. 宏只能在 Excel 软件中运行：如果你要在服务器上自动化运行宏，就需要安装 Excel 软件——但 Excel 软件是桌面软件，不是服务器软件，在服务器上运行 Excel 软件会占用大量的内存和 CPU 资源，而且很容易崩溃；
4. 宏的兼容性很差：比如 Excel 2003 及以前的版本用的是“.xls”格式的文件，Excel 2007 及以后的版本用的是“.xlsx”格式的文件——“.xls”格式的宏不能在“.xlsx”格式的文件中运行，除非你把文件保存为“.xlsm”格式（启用宏的 Excel 工作簿）；再比如 Windows 系统下的 Excel 宏和 Mac 系统下的 Excel 宏兼容性也很差，很多 Windows 系统下的 Excel 宏不能在 Mac 系统下运行，反之亦然。

1.2.2.4 痛点四：无法处理大规模数据

正如前面提到的，Excel 2007 及以后的版本最多只能处理1048576 行、16384 列的数据——如果数据量超过了这个限制，Excel 就会报错，甚至直接崩溃。

而且，就算数据量没有超过这个限制，纯手工操作 Excel 的效率也会非常低——比如处理 100 万行、10 列的数据，用 Excel 的“筛选”功能可能需要几分钟才能筛选出符合条件的数据，用 Excel 的“数据透视表”功能可能需要几十分钟才能生成统计结果，用 Excel 的公式计算功能可能需要几个小时才能计算完成。

1.2.2.5 痛点五：难以协作

纯手工操作 Excel 的协作性极低——如果多个同事需要同时处理同一个 Excel 文件，就会遇到“文件锁定”的问题（Excel 默认是“独占模式”打开文件的，也就是说，一个人打开了文件，另一个人就只能以“只读模式”打开文件，不能修改）；如果多个同事分别修改了同一个 Excel 文件的不同副本，最后合并的时候就会非常麻烦，很容易出现冲突。

虽然 Excel 2013 及以后的版本推出了“协同编辑（Co-Authoring）”功能，但协同编辑功能也有很多限制：

1. 协同编辑功能只能在 OneDrive、OneDrive for Business、SharePoint Online 等云端存储服务中使用——如果你的 Excel 文件存储在本地电脑或本地服务器上，就不能使用协同编辑功能；
2. 协同编辑功能的兼容性很差：比如 Excel 2013 及以后的版本才能使用协同编辑功能，Excel 2010 及以前的版本不能使用；再比如 Windows 系统下的 Excel、Mac 系统下的 Excel、Excel Online、Excel for Android、Excel for iOS 之间的协同编辑功能兼容性也不是很好；
3. 协同编辑功能容易出现数据丢失或冲突：虽然微软声称协同编辑功能可以“实时同步”多个同事的修改，但在实际使用中，经常会出现数据丢失或冲突的情况——尤其是当多个同事同时修改同一个单元格或同一个区域的时候。

1.2.3 第二类：用简单的脚本/低代码/无代码工具——入门门槛较高、可扩展性有限、容错机制不全、难以处理复杂任务

既然纯手工操作 Excel 有这么多痛点，那有没有更好的方法呢？当然有——那就是用简单的脚本/低代码/无代码工具。

这一类方法又可以细分为以下三小类：

1. 第二大类第一小类：用简单的脚本（比如 Python + Pandas/Polars、R + dplyr/readr、JavaScript + SheetJS 等）；
2. 第二大类第二小类：用低代码数据处理工具（比如 Power Query、Power Automate 桌面版、Tableau Prep、Alteryx Designer Core 等）；
3. 第二大类第三小类：用无代码数据处理工具（比如 Zapier、Make（原 Integromat）、Airtable Automations、Google Sheets App Scripts 等）。

接下来，我们分别来看看每一小类方法的具体操作和痛点。

1.2.3.1 第二大类第一小类：用简单的脚本——入门门槛较高、可复用性较好但需要版本控制、容错机制不全、需要环境隔离、难以处理大规模数据（除非用分布式计算框架）

用简单的脚本处理 Excel 和 CSV 数据是很多技术人员最常用的数据处理方法——它的具体操作就是：用 Python/R/JavaScript 等编程语言，结合 Pandas/Polars/dplyr/readr/SheetJS 等数据处理库，编写脚本处理数据，最后运行脚本。

这种方法的优点有很多：

1. 效率极高：用脚本处理数据的效率完全取决于编程语言和数据处理库的性能——比如 Python + Polars 的性能比 Python + Pandas 快 5-10 倍，比纯手工操作 Excel 快几十倍甚至几百倍；而且用脚本处理数据是自动化的、可并行的——你可以同时处理多个步骤或多个文件，不需要一直盯着电脑屏幕；
2. 出错率较低：只要你写的脚本逻辑是正确的，就不会出现人为操作失误的问题；而且脚本可以批量处理数据格式不一致、数据质量问题等；
3. 可复用性较好：你可以把写好的脚本保存下来，下次处理类似的任务的时候，只需要修改一下数据源路径和参数即可；而且你可以用 Git/GitHub/GitLab 等版本控制工具管理脚本，方便追踪修改历史、回滚错误版本、协作开发；
4. 可以处理大规模数据：虽然 Pandas/Polars/dplyr/readr/SheetJS 等数据处理库主要是“内存计算（In-Memory Computing）”——也就是说，它们需要把整个数据集加载到内存中才能处理，但如果你的电脑内存足够大（比如 32GB、64GB、128GB），就可以处理几百万行甚至几千万行的数据；如果数据量更大（比如几亿行甚至几十亿行），你可以用分布式计算框架（比如 Spark、Dask、Ray 等）处理；
5. 可扩展性极强：你可以用脚本调用任何工具、任何 API、任何数据库——比如你可以用 Pandas 读取 Excel/CSV 数据，用 Great Expectations 检查数据质量，用 PyCaret 做机器学习预测，用 Plotly 生成可视化图表，用 SQLAlchemy 把结果保存到 PostgreSQL 数据库中，用 Airflow 做任务调度，用 Sentry 做错误监控与告警；
6. 可以在任何环境中运行：你可以在本地电脑、本地服务器、云服务器（比如 AWS EC2、Azure VM、Google Cloud Compute Engine）、容器（比如 Docker、Kubernetes）中运行脚本——不需要安装 Excel 软件。

但是，这种方法的缺点也很明显，我们可以把它们总结为以下五大痛点：

1. 痛点一：入门门槛较高——虽然 Python/R/JavaScript 等编程语言的入门门槛比 C/C++/Java 等低，但对于非技术人员（比如业务分析师、数据分析师助理、市场运营人员）来说，仍然是一个很大的障碍——他们不仅需要学习编程语言的基本语法，还需要学习 Pandas/Polars/dplyr/readr/SheetJS 等数据处理库的 API，甚至还需要学习 Git/GitHub/GitLab 等版本控制工具、Docker/Kubernetes 等容器技术、Airflow/Kestra/Prefect 等任务调度工具；
2. 痛点二：容错机制不全——虽然你可以在脚本中添加 try-except 语句来捕获异常，但很多技术人员（尤其是新手）往往会忘记添加，或者添加的 try-except 语句不够完善——比如只捕获了 Pandas 的异常，没有捕获 OpenPyXL 的异常；或者捕获了异常后，只是简单地打印了一个错误信息，没有保存中间数据，没有发送告警通知，没有记录详细的日志；
3. 痛点三：需要环境隔离——不同的脚本可能需要不同版本的编程语言和数据处理库——比如脚本 A 需要 Python 3.9 和 Pandas 1.5.3，脚本 B 需要 Python 3.11 和 Pandas 2.2.2——如果不做环境隔离，就会出现“依赖冲突（Dependency Conflict）”的问题，导致脚本无法运行；虽然你可以用 Poetry/Pipenv/Conda/Virtualenv 等工具做环境隔离，但对于非技术人员来说，仍然是一个很大的障碍；
4. 痛点四：难以处理复杂的、模糊的自然语言指令——比如用户输入的任务是“帮我处理一下这个 Excel 文件，数据要干净一点，然后做一些有用的分析，生成一些好看的图表”——这样的指令对于脚本来说是完全无法理解的，因为脚本只能处理“明确的、可量化的、结构化的指令”——你必须把任务拆解成“明确的、可量化的、结构化的步骤”，然后编写脚本实现每个步骤；
5. 痛点五：可观测性与可调试性较差——虽然你可以在脚本中添加 logging 模块来记录日志，用 pytest 来写单元测试，但很多技术人员（尤其是新手）往往会忘记添加，或者添加的 logging 模块不够完善——比如日志的级别设置不合理（比如只记录 ERROR 级别的日志，不记录 INFO 级别的日志），日志的格式不够清晰（比如没有记录时间戳、脚本名称、函数名称、行号等）；而且如果脚本运行失败，你只能通过查看日志来排查问题，没有一个可视化的调试面板，很难快速定位问题所在。

1.2.3.2 第二大类第二小类：用低代码数据处理工具——入门门槛较低、可观测性与可调试性较好、容错机制较全、可扩展性有限、需要付费、难以处理大规模数据

用低代码数据处理工具处理 Excel 和 CSV 数据是很多业务分析师和数据分析师助理最常用的数据处理方法——它的具体操作就是：打开低代码数据处理工具，导入 Excel/CSV 数据，然后用拖拽式的界面（Drag-and-Drop Interface）添加数据处理步骤（比如去重、填充缺失值、转换数据类型、删除异常值、分组聚合、数据合并、数据拆分、数据可视化等），最后运行工具，保存结果。

这种方法的优点有很多：

1. 入门门槛较低——几乎所有会用电脑的人都能在几个小时内学会基本的操作，不需要学习编程语言的基本语法和数据处理库的 API；
2. 可观测性与可调试性较好——低代码数据处理工具通常都提供一个可视化的“数据流图（Data Flow Diagram）”，你可以实时查看每个步骤的输入数据、输出数据、执行状态、执行时间；如果某个步骤运行失败，工具会直接在数据流图上标记出来，并且提供详细的错误信息和调试建议；
3. 容错机制较全——低代码数据处理工具通常都内置了完善的容错机制，比如“自动重试（Auto-Retry）”、“中间数据缓存（Intermediate Data Caching）”、“错误数据分流（Error Data Routing）”等；
4. 可以处理复杂的、半结构化的指令——比如有些低代码数据处理工具（比如 Power Query、Alteryx Designer Core）已经集成了 LLM（比如 GPT-4 Turbo、Claude 3 Sonnet），你可以用自然语言输入任务，工具会自动把任务拆解成数据处理步骤，生成数据流图——当然，目前这些工具的 LLM 集成还处于早期阶段，处理复杂的、模糊的自然语言指令的能力还比较有限；
5. 可复用性较好——你可以把生成的数据流图保存下来，下次处理类似的任务的时候，只需要修改一下数据源路径和参数即可；而且你可以用工具自带的版本控制功能管理数据流图，方便追踪修改历史、回滚错误版本、协作开发；
6. 可以在任何环境中运行——有些低代码数据处理工具（比如 Power Query、Google Sheets App Scripts）是内置在 Excel/Google Sheets 中的，有些（比如 Power Automate 桌面版、Tableau Prep、Alteryx Designer Core）是桌面软件，有些（比如 Power Automate 云端版、Alteryx Designer Cloud）是云端服务——不需要安装额外的软件（除了桌面版）。

但是，这种方法的缺点也很明显，我们可以把它们总结为以下五大痛点：

1. 痛点一：可扩展性有限——低代码数据处理工具通常都只内置了一些常见的数据处理步骤，如果你需要处理一些特殊的、自定义的任务（比如“根据身份证号前 6 位推导员工的出生地和性别，根据身份证号第 7-14 位推导员工的年龄和星座”），就需要编写自定义的脚本（比如 Power Query 的 M 语言、Alteryx Designer Core 的 Python/R 脚本、Google Sheets App Scripts 的 JavaScript 代码）——而自定义脚本的入门门槛又很高，很多非技术人员不会写；
2. 痛点二：需要付费——很多低代码数据处理工具（比如 Tableau Prep、Alteryx Designer Core、Alteryx Designer Cloud）的价格非常昂贵——比如 Alteryx Designer Core 的年费大约是5000-10000 美元/用户，Alteryx Designer Cloud 的年费大约是10000-20000 美元/用户——对于中小企业和个人用户来说，这是一笔很大的开支；虽然有些低代码数据处理工具（比如 Power Query、Power Automate 桌面版、Google Sheets App Scripts）是免费的，但它们的功能相对有限；
3. 痛点三：难以处理大规模数据——和 Excel 一样，很多低代码数据处理工具主要是“内存计算”——也就是说，它们需要把整个数据集加载到内存中才能处理；如果数据量超过了电脑的内存限制，工具就会报错，甚至直接崩溃；虽然有些低代码数据处理工具（比如 Alteryx Designer Core、Alteryx Designer Cloud）支持“分布式计算”，但分布式计算的配置非常复杂，而且需要额外的费用；
4. 痛点四：难以处理复杂的、模糊的自然语言指令——正如前面提到的，目前这些工具的 LLM 集成还处于早期阶段，处理复杂的、模糊的自然语言指令的能力还比较有限；比如用户输入的任务是“帮我处理一下这个 Excel 文件，数据要干净一点，然后做一些有用的分析，生成一些好看的图表”——工具可能只会生成一些基本的数据清洗步骤（比如去重、填充缺失值）和基本的描述性统计图表（比如柱状图、饼图），但不会处理特殊的数据质量问题（比如拼写错误、数据格式不一致），也不会做深入的数据分析（比如相关性分析、机器学习预测）；
5. 痛点五：难以与其他工具链整合——虽然有些低代码数据处理工具（比如 Power Automate、Make）提供了很多 API 连接器（API Connectors），可以与其他工具链整合，但整合的深度和灵活性仍然不如脚本；比如你很难用低代码数据处理工具调用 Great Expectations 检查数据质量，调用 PyCaret 做机器学习预测，调用 SQLAlchemy 把结果保存到 PostgreSQL 数据库中，调用 Airflow 做任务调度，调用 Sentry 做错误监控与告警——除非你编写自定义的脚本或 API 连接器。

1.2.3.3 第二大类第三小类：用无代码数据处理工具——入门门槛极低、可观测性与可调试性较好、容错机制较全、可扩展性非常有限、需要付费、处理数据量有限、处理速度较慢

用无代码数据处理工具处理 Excel 和 CSV 数据是很多市场运营人员和小型企业主最常用的数据处理方法——它的具体操作就是：打开无代码数据处理工具的 Web 界面，注册账号，创建一个“自动化工作流（Automation Workflow）”，添加“触发条件（Trigger）”（比如“当 OneDrive 中的某个文件夹上传了新的 Excel/CSV 文件时”、“当每天早上 9 点时”），添加“动作（Actions）”（比如“读取 Excel/CSV 文件”、“去重”、“填充缺失值”、“转换数据类型”、“发送邮件”、“保存到 Google Sheets”），最后启动工作流。

这种方法的优点有很多：

1. 入门门槛极低——几乎所有会用电脑的人都能在几分钟内学会基本的操作，不需要学习任何编程语言、任何数据处理库、任何版本控制工具；
2. 可观测性与可调试性较好——无代码数据处理工具通常都提供一个可视化的“工作流图（Workflow Diagram）”，你可以实时查看每个动作的输入数据、输出数据、执行状态、执行时间；如果某个动作运行失败，工具会直接在工作流图上标记出来，并且提供详细的错误信息和调试建议；
3. 容错机制较全——无代码数据处理工具通常都内置了完善的容错机制，比如“自动重试”、“中间数据缓存”、“错误数据分流”等；
4. 可以与很多其他工具链整合——无代码数据处理工具通常都提供了几千甚至几万个 API 连接器，可以与 Excel/Google Sheets/OneDrive/SharePoint/Slack/Discord/钉钉/企业微信/Gmail/Outlook 等几乎所有常用的工具链整合；
5. 可以在云端自动运行——无代码数据处理工具都是云端服务，不需要安装任何软件，不需要维护任何服务器，只需要注册账号，创建工作流，启动工作流，工具就会在云端自动运行；
6. 可复用性较好——你可以把创建的工作流保存下来，下次处理类似的任务的时候，只需要复制工作流，修改一下触发条件和参数即可；而且你可以用工具自带的版本控制功能管理工作流，方便追踪修改历史、回滚错误版本、协作开发。

但是，这种方法的缺点也非常明显，我们可以把它们总结为以下六大痛点：

1. 痛点一：可扩展性非常有限——无代码数据处理工具通常都只内置了一些非常基本的数据处理动作（比如“读取 Excel/CSV 文件”、“去重”、“填充缺失值（只能用平均值、中位数、众数、固定值填充）”、“转换数据类型（只能转换文本、数字、日期等基本数据类型）”、“发送邮件”、“保存到 Google Sheets”），如果你需要处理一些特殊的、自定义的任务（比如“根据身份证号前 6 位推导员工的出生地和性别，根据身份证号第 7-14 位推导员工的年龄和星座”、“删除工资低于当地最低工资标准或高于 CEO 工资 10 倍的异常值”、“按部门分组聚合计算平均工资、中位数工资、最高工资、最低工资、员工人数”、“生成每个部门的工资分布柱状图和饼图”），就需要编写自定义的代码（比如 Zapier 的 Code by Zapier、Make 的 Custom Code、Airtable Automations 的 Scripting App）——而自定义代码的入门门槛又很高，很多非技术人员不会写；
2. 痛点二：需要付费——虽然很多无代码数据处理工具都提供了“免费套餐（Free Plan）”，但免费套餐的限制非常多——比如 Zapier 的免费套餐最多只能创建 5 个工作流，每个工作流最多只能有 2 个动作，每个月最多只能执行 100 次任务；Make 的免费套餐最多只能创建 3 个工作流，每个工作流最多只能有 6 个动作，每个月最多只能执行 1000 次任务；如果你的任务量比较大，或者需要创建更多的工作流、添加更多的动作，就需要购买“付费套餐（Paid Plan）”——而付费套餐的价格也不便宜，比如 Zapier 的 Starter 套餐年费大约是240 美元/用户，Professional 套餐年费大约是600 美元/用户，Team 套餐年费大约是1200 美元/用户；Make 的 Basic 套餐年费大约是144 美元/用户，Standard 套餐年费大约是432 美元/用户，Pro 套餐年费大约是1080 美元/用户；
3. 痛点三：处理数据量有限——无代码数据处理工具的免费套餐和付费套餐通常都对“每次任务处理的数据量”和“每个月处理的总数据量”有严格的限制——比如 Zapier 的免费套餐每次任务最多只能处理 1000 行数据，每个月最多只能处理 100000 行数据；Professional 套餐每次任务最多只能处理 10000 行数据，每个月最多只能处理 1000000 行数据；Make 的免费套餐每次任务最多只能处理 10000 行数据，每个月最多只能处理 1000000 行数据；Pro 套餐每次任务最多只能处理 100000 行数据，每个月最多只能处理 10000000 行数据；如果你的数据量超过了这些限制，工具就会报错，甚至直接终止任务；
4. 痛点四：处理速度较慢——无代码数据处理工具都是云端服务，处理速度取决于网络速度和工具的服务器负载——如果网络速度比较慢，或者工具的服务器负载比较高，处理一个简单的任务可能需要几分钟甚至几十分钟；
5. 痛点五：难以处理复杂的、模糊的自然语言指令——目前，几乎所有的无代码数据处理工具都没有集成 LLM（至少没有深度集成），你只能通过拖拽式的界面添加触发条件和动作，不能用自然语言输入任务；
6. 痛点六：数据安全与隐私问题——无代码数据处理工具都是云端服务，你需要把你的 Excel/CSV 数据上传到工具的服务器上——如果你的数据是敏感数据（比如公司员工的工资数据、客户的个人信息数据），就会存在数据安全与隐私问题——虽然很多无代码数据处理工具都声称自己符合 GDPR、CCPA 等数据安全与隐私法规，但仍然不能完全排除数据泄露的风险。

1.2.4 第三类：用企业级的数据处理工具/平台——功能强大、可扩展性极强、可以处理大规模数据、入门门槛极高、价格极其昂贵、需要专业的技术团队维护

既然前面两类方法都有这么多痛点，那有没有“完美”的方法呢？——当然有，但它只适合大型企业——那就是用企业级的数据处理工具/平台。

这一类方法又可以细分为以下三小类：

1. 第三大类第一小类：用企业级的数据仓库/数据湖工具（比如 Snowflake、BigQuery、Redshift、Databricks Lakehouse 等）；
2. 第三大类第二小类：用企业级的数据集成工具（比如 Fivetran、Stitch、Talend Data Fabric、Informatica Intelligent Cloud Services 等）；
3. 第三大类第三小类：用企业级的 AI 数据分析平台（比如 Tableau GPT、Power BI Copilot、ThoughtSpot Sage、MicroStrategy AI 等）。

接下来，我们分别来看看每一小类方法的具体操作和痛点——不过，由于这一类方法主要适合大型企业，我们不会展开得太详细，只是简单介绍一下。

1.2.4.1 第三大类第一小类：用企业级的数据仓库/数据湖工具——功能强大、可扩展性极强、可以处理超大规模数据、入门门槛极高、价格极其昂贵、需要专业的技术团队维护

用企业级的数据仓库/数据湖工具处理 Excel 和 CSV 数据的具体操作就是：用企业级的数据集成工具（比如 Fivetran、Stitch）把 Excel/CSV 数据从本地电脑、本地服务器、云存储服务（比如 AWS S3、Azure Blob Storage、Google Cloud Storage）中导入到数据仓库/数据湖工具中，然后用 SQL 或 Python/R 等编程语言处理数据，最后用企业级的 BI 工具（比如 Tableau、Power BI、ThoughtSpot）做数据分析和可视化。

这种方法的优点有很多：

1. 功能强大——企业级的数据仓库/数据湖工具通常都内置了完善的数据处理功能（比如数据清洗、数据转换、数据合并、数据分组聚合、机器学习预测等）；
2. 可扩展性极强——企业级的数据仓库/数据湖工具通常都是“云原生（Cloud-Native）”的，可以根据数据量的大小和任务的复杂度自动扩展或收缩服务器资源；
3. 可以处理超大规模数据——企业级的数据仓库/数据湖工具通常都是“分布式计算”的，可以处理几亿行甚至几十亿行、几百亿行的数据；
4. 数据安全与隐私性较好——企业级的数据仓库/数据湖工具通常都符合 GDPR、CCPA、HIPAA 等严格的数据安全与隐私法规，支持数据加密、访问控制、审计日志等功能；
5. 可以与很多其他工具链整合——企业级的数据仓库/数据湖工具通常都提供了很多 API 连接器，可以与企业级的数据集成工具、BI 工具、AI 工具、应用程序等整合。

但是，这种方法的缺点也非常明显：

1. 入门门槛极高——你需要学习 SQL 的高级语法（比如窗口函数、CTE、PIVOT/UNPIVOT 等），需要学习企业级的数据仓库/数据湖工具的架构和 API，需要学习云原生技术（比如 Docker、Kubernetes、AWS/Azure/Google Cloud 等）；
2. 价格极其昂贵——企业级的数据仓库/数据湖工具的价格通常都是“按使用量付费（Pay-as-you-go）”的——比如 Snowflake 的价格大约是2-4 美元/计算小时，23-40 美元/TB/月（存储费用）；BigQuery 的价格大约是5 美元/TB（查询费用），23 美元/TB/月（存储费用）；如果你的数据量比较大，或者任务量比较大，每个月的费用可能会达到几万甚至几十万美元；
3. 需要专业的技术团队维护——你需要一个专业的技术团队（包括数据工程师、数据科学家、云工程师等）来维护数据仓库/数据湖工具，来处理数据集成、数据清洗、数据转换、数据建模、任务调度、错误监控与告警等工作；
4. 难以处理复杂的、模糊的自然语言指令——虽然很多企业级的数据仓库/数据湖工具已经集成了 LLM（比如 Snowflake 的 Snowflake Copilot、BigQuery 的 BigQuery ML + PaLM 2），但处理复杂的、模糊的自然语言指令的能力仍然比较有限。

1.2.4.2 第三大类第二小类：用企业级的数据集成工具——功能强大、可扩展性极强、可以处理超大规模数据、入门门槛较高、价格极其昂贵、需要专业的技术团队维护

用企业级的数据集成工具处理 Excel 和 CSV 数据的具体操作就是：打开企业级的数据集成工具，创建一个“数据集成管道（Data Integration Pipeline）”，添加“数据源（