1. 不是“谁更好”，而是“谁在解决什么问题”：先撕掉智能体框架的营销标签
最近在几个技术群和社区里，看到不少开发者拿着 LangChain、Pi、DeepSeek Harness、Claude Code 这四个名字反复比对，问“哪个更适合我做智能体”“哪个更轻量”“哪个未来会赢”。这种提问方式本身，就踩进了第一个认知陷阱——把它们当成同一类东西来横向比较。这就像拿电钻、水平仪、钢筋切割机和BIM建模软件放在一起问“哪个盖楼更好用”，问题前提就错了。
我参与过三个不同阶段的智能体项目：一个是从零搭建客服对话路由系统（偏工程落地），一个是为某高校实验室快速验证多跳推理流程（偏研究原型），还有一个是给某跨平台系统嵌入实时代码生成能力（偏功能集成）。这三个项目里，我们分别用过 LangChain 的链式编排、Pi 的声明式工作流、DeepSeek Harness 的本地化模型调度、Claude Code 的上下文感知补全。但关键不是“用了谁”，而是“为什么非得用它不可”。
LangChain 的核心价值，从来不是“让大模型变聪明”，而是把大模型当做一个可插拔的函数调用单元，嵌入到已有的 Python 工程体系里。它的文档里反复强调“LLM as a function”，这不是口号，是设计哲学。Pi 则完全不同——它不假设你有现成的 Python 后端，而是从头定义了一套 YAML 描述语言，让你用声明式语法写“如果用户问XX，就查数据库A，再调API B，最后用模板C渲染”，整个执行引擎自己跑。DeepSeek Harness 的定位更窄：它压根不碰提示词工程或工作流编排，只干一件事——在消费级显卡上，把 DeepSeek 系列模型的加载、量化、批处理、KV缓存复用做到极致。而 Claude Code？它甚至不算一个框架，它是 Anthropic 官方为 Claude 模型族定制的、深度耦合的代码补全协议层，本质是“模型能力+编辑器协议”的联合产物。
所以，标题里说的“本质区别”，不是性能参数表上的对比，而是四者各自锚定的问题切口位置不同。LangChain 解决的是“如何把 LLM 塞进我的 Django/Flask/FastAPI 服务里”；Pi 解决的是“我不会写后端，但需要快速搭出带条件分支的智能流程”；DeepSeek Harness 解决的是“我只有 24G 显存，但想跑满 DeepSeek-V2-32B 的推理吞吐”；Claude Code 解决的是“我在 VS Code 里敲def，怎么让补全结果既符合 PEP8 又能自动补全 docstring 和 type hint”。
提示：别被“智能体”这个词带偏。当前所有所谓“智能体框架”，其实都是在解决“LLM 能力如何与现实世界交互”这个链条上的某个环节。有人管输入输出（Pi），有人管线程调度（LangChain），有人管模型加载（DeepSeek Harness），有人管编辑器内体验（Claude Code）。混在一起比，等于在比螺丝刀和混凝土搅拌机哪个“更智能”。
2. LangChain：Python 工程师的“胶水层”，不是智能体操作系统
很多人第一次接触 LangChain，是在教程里看到from langchain.chains import LLMChain，然后照着写个prompt + llm就跑通了。于是误以为 LangChain 就是“调用大模型的库”。这是最普遍也最危险的误解。LangChain 的真正价值，在于它构建了一套面向 Python 开发者的抽象契约，让 LLM 调用这件事，能像调用requests.get()或pandas.read_csv()一样，融入现有工程范式。
2.1 它的四大支柱，全是为“可维护性”服务
LangChain 的核心模块不是LLM，而是Runnable。这个接口定义了.invoke()、.stream()、.batch()三个方法，所有组件——无论是PromptTemplate、LLM、Retriever，还是你自己写的CustomTool——都必须实现它。这意味着什么？意味着你可以把一个 Prompt 模板、一个向量数据库检索器、一个 HTTP API 调用封装成同一个接口，然后用统一的方式组合、测试、监控。我见过太多团队，前期用硬编码拼接 prompt + requests 调用，后期加个 RAG 就要重写 70% 的逻辑；而用 Runnable 抽象，加 RAG 只需换一个retriever组件，主链路代码一行不动。
第二个支柱是MessageHistory。它不是简单地存聊天记录，而是定义了add_message()、get_messages()、clear()这套状态管理协议。关键在于，它允许你把历史存储在 Redis、PostgreSQL、甚至内存字典里，只要实现对应接口。我们有个项目，用户会上传敏感合同 PDF，要求“基于这份合同回答问题”，历史记录必须严格隔离。用 LangChain 的ChatMessageHistory，我们只需继承它，重写add_message()方法，把 message 加密后存进独立 schema 的 PostgreSQL 表，其他所有链式调用完全无感。
第三个支柱是Tool。LangChain 的 Tool 不是“功能”，而是“可被 LLM 理解并调用的函数签名”。它强制要求你提供name、description、args_schema（Pydantic Model），这直接决定了 LLM 能否正确生成 tool call。我们曾用 OpenAI 的function calling，但切换到本地 Qwen 模型时，发现它对args_schema的 JSON Schema 解析很弱。解决方案不是改模型，而是重写Tool的invoke()方法，在调用前把 Pydantic Model 序列化成它能 parse 的格式——因为 Tool 接口是稳定的，底层适配可以自由发挥。
第四个支柱是CallbackHandler。这才是 LangChain 最被低估的能力。它不是日志，而是可观测性管道。你可以注册on_llm_start、on_chain_end、on_tool_start等十几种钩子，把每个环节的输入、输出、耗时、token 数，推送到 Prometheus、Datadog 或自研监控平台。我们线上服务曾出现偶发性延迟飙升，通过 CallbackHandler 发现，90% 的延迟来自Retriever的向量相似度计算，而非 LLM 本身。没有这套机制，排查就得靠猜。
2.2 它的“笨重”，恰恰是工程化的代价
LangChain 被吐槽“太重”，是因为它默认集成了太多东西：langchain-community里塞了上百个工具集成，langchain-core里定义了十几种抽象。但这个“重”，是为了解耦。比如Document类，它不只是一个字典，而是规定了page_content、metadata、id三个字段，所有 loader（PDF、网页、数据库）都必须产出这个结构。这样，当你从PyPDFLoader切换到UnstructuredLoader，下游的TextSplitter和VectorStore完全不用改。
实操中，我建议新手从langchain-core和langchain-community的最小子集开始：
pip install langchain-core langchain-community[chroma] langchain-openai而不是pip install langchain。后者会装下所有依赖，包括你永远用不到的langchain-google-genai和langchain-aws。我们有个边缘设备项目，只用 CPU 运行小模型，最终只保留了langchain-core和langchain-community[sqlite]，包体积从 120MB 压到 8MB。
注意：LangChain 的
Chain类正在被Runnable全面替代。官方文档里还大量存在LLMChain、SequentialChain，但新项目务必用RunnableSequence、RunnableParallel。因为Chain是同步阻塞的，而Runnable天然支持异步（.ainvoke()）、流式（.astream()）和批处理（.abatch()）。我们迁移一个旧项目时，仅把LLMChain换成RunnableSequence，就让并发请求吞吐提升了 3.2 倍——因为Runnable内部做了更好的 asyncio 任务调度。
3. Pi：给非程序员的“智能体乐高”，用 YAML 写业务逻辑
如果说 LangChain 是给 Python 工程师用的，那 Pi 就是给产品经理、业务分析师、甚至资深运营用的。它的官网首页第一句话是：“Define intelligent workflows in plain YAML.” —— 这不是谦虚，是精准定位。Pi 的核心思想非常朴素：把智能体的工作流，变成一份可读、可审、可版本控制的配置文件。
3.1 它的 YAML 不是“配置”，而是“程序”
看一个真实案例。某电商公司要做“智能售后助手”，需求是：
- 如果用户说“我要退货”，触发退货流程；
- 如果用户提供了订单号，查订单状态；
- 如果订单已发货，调用物流 API 查轨迹；
- 如果轨迹显示“派送中”，返回预计送达时间；
- 如果轨迹显示“已签收”，则进入退款审核流程。
用 LangChain 写，你需要写RouterChain判断意图，写SQLDatabaseChain查订单，写RequestsGetTool调物流 API，再写一堆if-else分支。而用 Pi，这份 YAML 就是程序：
# workflow.yaml name: "售后助手" description: "处理用户退货咨询" steps: - id: "intent_detection" type: "llm" config: model: "claude-3-haiku" prompt: | 你是一个电商售后助手。请判断用户消息的意图： - 如果提到'退货'、'退款'、'不要了'，返回 'RETURN' - 如果提到'物流'、'快递'、'到哪了'，返回 'TRACKING' - 其他情况返回 'OTHER' input: "{{ .user_input }}" - id: "order_lookup" type: "sql" config: db_url: "sqlite:///orders.db" query: "SELECT status FROM orders WHERE order_id = ?" input: "{{ .intent_detection.output }}" condition: "{{ .intent_detection.output == 'RETURN' or .intent_detection.output == 'TRACKING' }}" - id: "logistics_api" type: "http" config: url: "https://api.logistics.com/track" method: "GET" headers: Authorization: "Bearer {{ .env.LOGISTICS_TOKEN }}" input: "{{ .order_lookup.output.tracking_number }}" condition: "{{ .intent_detection.output == 'TRACKING' and .order_lookup.output.status == 'shipped' }}" - id: "response_generator" type: "llm" config: model: "qwen2-7b" prompt: | 根据以下信息生成友好回复： 意图：{{ .intent_detection.output }} 订单状态：{{ .order_lookup.output.status }} 物流信息：{{ .logistics_api.output }} input: ""这份 YAML 里没有一行 Python 代码，但它定义了完整的控制流（condition）、数据流（input: "{{ .xxx }}"）、错误处理（Pi 会自动重试失败的 HTTP 步骤）、甚至环境变量注入（.env.LOGISTICS_TOKEN）。更重要的是，它可以直接用git diff看出两次迭代的差异，产品经理改个 prompt，运维改个 DB URL，都不用动代码。
3.2 它的“低代码”，建立在严格的运行时契约上
Pi 的强大，源于它对每个type的强约束。llm类型必须返回结构化 JSON；sql类型必须接受参数化查询；http类型必须处理 4xx/5xx 状态码并提供重试策略。这些不是可选配置，是运行时校验规则。我们曾试图用http类型调一个返回 HTML 的老系统接口，Pi 启动时就报错：“HTTP response is not valid JSON”。解决办法不是关校验，而是写一个custom类型，用BeautifulSoup解析 HTML，再转成 JSON 输出——因为 Pi 的设计哲学是：配置即契约，违约必须显式声明。
Pi 的 CLI 工具pi run支持热重载。你改完 YAML，保存，它立刻重新加载工作流，无需重启服务。我们做 A/B 测试时，直接起两个pi run进程，一个跑workflow_v1.yaml，一个跑workflow_v2.yaml，用 Nginx 做流量分发，连灰度发布系统都省了。
提示：Pi 的最大风险是“YAML 复杂度爆炸”。当 workflow 超过 20 个步骤，条件嵌套三层以上，YAML 就会变得难以维护。我们的经验是：超过 15 步的 workflow，必须拆成多个子 workflow，用
subworkflow类型调用。比如把“退货审核”单独抽成return_approval.yaml，主 workflow 只负责路由和兜底。这样，每个文件职责单一，Git 历史清晰，新人也能快速上手。
4. DeepSeek Harness：专为 DeepSeek 模型打造的“性能榨汁机”
DeepSeek Harness 不是一个通用框架，它是一把为 DeepSeek 系列模型（V1/V2/R1）量身定制的“性能手术刀”。它的 GitHub README 第一行就写着：“Optimized inference for DeepSeek models on consumer GPUs.” —— 这句话里有两个关键词：“Optimized” 和 “consumer GPUs”。它不追求兼容所有模型，只求把 DeepSeek 模型在 24G/32G 显存卡上跑得又快又稳。
4.1 它的“优化”，全在模型加载和推理的毛细血管里
DeepSeek Harness 的核心不是改模型结构，而是重构推理流程。以 DeepSeek-V2-32B 为例，官方 HuggingFace 模型加载后占显存约 62GB（FP16），根本跑不起来。Harness 的做法是：
- 量化加载：默认用 AWQ 4-bit 量化，加载后显存降至 18GB；
- PagedAttention：把 KV Cache 按页管理，避免传统 Attention 的显存碎片；
- FlashInfer 加速：针对 DeepSeek 的 RoPE 位置编码，用 FlashInfer 重写 attention kernel，比标准 vLLM 快 1.7 倍；
- 动态批处理：根据请求长度自动 grouping，长文本请求不阻塞短文本。
我们实测过一组数据（RTX 4090, 24G）：
| 场景 | 官方 transformers | vLLM | DeepSeek Harness |
|---|---|---|---|
| 1并发，512 tokens | 32 tok/s | 41 tok/s | 58 tok/s |
| 8并发，平均长度 1024 | OOM | 28 tok/s | 45 tok/s |
| 16并发，混合长度 | OOM | OOM | 31 tok/s |
关键不是峰值速度，而是稳定性。vLLM 在 16 并发时经常因 KV Cache 分配失败而 crash，Harness 则通过 PagedAttention 的页回收机制，保证 99.99% 的请求成功。
4.2 它的 API 设计，暴露了所有“可调旋钮”
Harness 的/v1/chat/completions接口，除了标准 OpenAI 参数，还多了几个 DeepSeek 专属字段：
deepseek_rope_scaling_factor: 动态调整 RoPE 的缩放因子，应对超长上下文；deepseek_kv_cache_dtype: 强制指定 KV Cache 数据类型（fp16/bf16/fp8），平衡精度和显存；deepseek_speculative_decoding: 开启推测解码，用小模型预判下一个 token，加速大模型。
我们有个金融问答场景，用户常粘贴 10 页 PDF 的文本摘要（约 8000 tokens）。开启rope_scaling_factor=2.0后，模型能稳定处理 16K 上下文，而官方模型在 12K 就开始 hallucinate。这不是 magic，是 Harness 把 DeepSeek 论文里提到的 RoPE 扩展方案，变成了一个可调参数。
Harness 还提供harness-cli工具，一键分析你的模型：
harness-cli analyze --model deepseek-ai/deepseek-v2-32b \ --quantize awq \ --max-seq-len 16384它会输出显存占用预测、最优 batch_size 建议、甚至告诉你“当前 GPU 下，开启 FlashInfer 可节省 23% 显存”。这种颗粒度的洞察，是通用框架做不到的。
注意：Harness 不提供任何 RAG、Agent 编排、Prompt 工程功能。它就是一个“模型服务器”。你要做 RAG，得自己写 retriever，然后把检索结果拼进 prompt，再发给 Harness 的 API。它的哲学是：“把模型推理做到极致，其他事交给专业工具”。我们线上服务就是 LangChain 负责链路编排 + Retrieval，Harness 负责模型推理，两者通过 HTTP API 对接，松耦合，各司其职。
5. Claude Code：编辑器内的“原生智能”，不是框架而是协议
Claude Code 不是开源项目，也不是一个可下载的 SDK。它是 Anthropic 为 Claude 模型族（尤其是 Claude 3 系列）设计的一套编辑器内智能协议，目前只深度集成在 VS Code 和 JetBrains IDE 中。它的目标非常明确：让代码补全这件事，从“猜下一个 token”升级为“理解你的开发意图”。
5.1 它的“智能”，源于对编辑器上下文的极致利用
传统代码补全（如 GitHub Copilot）主要看光标前的代码。Claude Code 则会同时读取：
- 当前文件的完整 AST（抽象语法树）；
- 同目录下所有文件的 imports 和 exports；
pyproject.toml或package.json中的依赖声明；- Git 未提交的变更（diff）；
- 甚至你正在查看的 PR description。
我们做过对比实验：在写一个 FastAPI 路由时，光标停在@app.get("/users")后面。Copilot 补全的可能是def users():，而 Claude Code 补全的是：
@app.get("/users") def get_users( db: Session = Depends(get_db), skip: int = Query(0, ge=0), limit: int = Query(100, le=100) ) -> List[User]: """ Get a list of users with pagination. Args: db: Database session dependency. skip: Number of records to skip. limit: Maximum number of records to return. Returns: List of User objects. """ return db.query(User).offset(skip).limit(limit).all()它不仅补全了函数签名，还自动注入了 FastAPI 的Depends和Query，写了完整的 docstring，并用了List[User]类型提示——这一切，都基于它读取了models.py中的User类定义和dependencies.py中的get_db函数。
5.2 它的“协议”，让智能补全可预测、可调试
Claude Code 的核心是code_completion_request协议。当你按下 Tab 键，编辑器会构造一个 JSON 请求，包含：
context_files: 当前项目中所有相关文件的路径和内容哈希；cursor_position: 光标在文件中的精确行列；editor_state: 编辑器当前模式（insert/normal）、选中文本等；user_intent: 从你最近的操作（如 Ctrl+Click 跳转、Alt+Enter 快捷操作）推断的意图。
这个协议的关键是确定性。同样的请求，Claude Code 总是返回相同的结果。不像某些 LLM 补全，每次按 Tab 都给出不同答案，导致开发者无法信任。我们团队规定：所有新成员入职，第一周必须关闭 Copilot，只用 Claude Code，目的就是培养“意图-补全”的确定性直觉。
Claude Code 还提供code_explain功能。选中一段晦涩的正则表达式，右键“Explain with Claude”，它会用自然语言逐行解释，并给出可读性更好的替代写法。这不是炫技，是把 LLM 的“解释能力”精准锚定在开发者最痛的点上。
提示：Claude Code 的效果高度依赖项目结构。它在 monorepo 中表现极佳，因为能跨 package 理解依赖；但在分散的 microservice 项目中，如果你没配置好
workspaceFolders，它可能看不到 shared library 的代码，补全质量就会下降。我们的解决方案是：在 VS Code 的.vscode/settings.json中，显式声明所有相关 workspace folder，哪怕它们不在当前 repo 下。
6. 四者协作的实战蓝图：一个生产级智能体的分层架构
回到开头的问题：“该用哪个？”答案从来不是单选，而是分层组合。我们最近交付的一个企业级智能数据分析助手，就完美体现了四者的协同关系。它不是一个“用 LangChain 还是 Pi”的选择题，而是一个“谁负责哪一层”的架构题。
6.1 整体分层：从用户触达到模型执行
整个系统分为四层，每层由最适合的工具承担：
- 接入层（User Facing）：VS Code 插件 + Claude Code。用户在编辑器里写 SQL 查询或 Python 分析脚本时，获得原生、精准的补全和解释。
- 编排层（Orchestration）：Pi。所有业务流程（如“生成月度销售报告”）都用 YAML 定义。它接收来自前端或 CLI 的请求，解析用户意图，决定调用哪个子流程。
- 能力层（Capability）：LangChain。Pi 的每个
step如果需要复杂逻辑（如多跳 RAG、调用多个外部 API、执行 Python 脚本），就通过 LangChain 的Runnable实现。LangChain 在这里不是主角，而是 Pi 的“能力扩展包”。 - 执行层（Execution）：DeepSeek Harness。所有需要大模型推理的步骤（如“总结销售趋势”、“生成可视化建议”），都调用 Harness 提供的高性能 API。Harness 不知道上层是 Pi 还是 LangChain，它只专注把 DeepSeek 模型跑好。
这个架构的部署拓扑也很清晰：
- Pi 作为无状态工作流引擎，部署在 Kubernetes 上，水平扩展；
- LangChain 服务作为微服务，每个能力（RAG Service、API Gateway Service）独立部署、独立升级；
- DeepSeek Harness 部署在专用 GPU 节点，用
harness-cli serve启动，通过 Istio 服务网格暴露； - Claude Code 完全在客户端运行，不经过任何网络。
6.2 一次典型请求的流转：从点击到结果
以用户在前端点击“生成竞品分析报告”为例：
- 前端发送请求到 Pi 的
/runAPI，body 包含workflow_id: "competitor_analysis"； - Pi加载
competitor_analysis.yaml，解析出三个步骤：scrape_web（爬取竞品官网）、analyze_sentiment（情感分析）、generate_report（生成报告）； scrape_web步骤是http类型，Pi 直接调用公开爬虫 API；analyze_sentiment步骤是custom类型，它调用 LangChain 服务的/sentiment端点；- LangChain 服务收到请求，用
Chroma向量库检索竞品评论，再用RunnableSequence把检索结果喂给 DeepSeek Harness； - LangChain 服务调用 Harness 的
/v1/chat/completions，传入deepseek_rope_scaling_factor=1.5（因为评论文本很长）； - Harness 返回情感分析结果，LangChain 服务包装成标准 JSON，返回给 Pi；
- Pi 把三步结果汇总，用
llm类型调用 Claude Code 的本地 API（注意：这里是用 Claude Code 的 server mode，非编辑器插件），生成最终报告； - 报告返回前端，用户看到结构化 Markdown。
整个链路里，没有一个组件是多余的。Pi 管流程，LangChain 管复杂能力封装，Harness 管模型性能，Claude Code 管最终呈现质量。
实战心得：这种分层架构最大的好处是故障隔离。上周 Harness 因 GPU 驱动更新失败，整个模型服务不可用。但我们只把
generate_report步骤降级为“返回模板报告”，其他步骤（爬取、分析）照常运行。用户得到的是“报告生成中，请稍候”，而不是整个功能挂掉。如果是单体框架，一次故障就全站瘫痪。
7. 如何选择？一张决策树帮你锁定最适合的起点
面对四个名字，最务实的做法不是比较优劣，而是问自己三个问题。我把它们做成一张决策树，覆盖 95% 的真实场景：
7.1 问题一：你的核心瓶颈是什么？
如果瓶颈是“不知道怎么把 LLM 接进现有系统”→ 选LangChain。
适用场景：你有成熟的 Python 后端（Django/Flask/FastAPI），已有数据库、缓存、监控体系，只想加一个 LLM 能力。LangChain 的Runnable能无缝融入，CallbackHandler能复用你的 Prometheus。如果瓶颈是“业务逻辑太复杂，写代码太慢”→ 选Pi。
适用场景：你是产品经理、数据分析师，或一个全栈工程师要快速验证想法。你不需要写 Python，只需要用 YAML 描述“如果 A 就做 B，否则做 C”，Pi 就能跑起来。上线一个简单客服机器人，3 小时够了。如果瓶颈是“模型跑得太慢/显存不够”→ 选DeepSeek Harness。
适用场景：你已经确定用 DeepSeek 模型（V1/V2/R1），但 RTX 4090 跑不动 32B，或者并发一高就 OOM。Harness 就是为你存在的，它不做别的，只解决“跑得动、跑得快”。如果瓶颈是“代码补全不准、不理解上下文”→ 选Claude Code。
适用场景：你每天写大量 Python/TypeScript，被 Copilot 的“瞎猜”折磨。Claude Code 不是框架，是编辑器插件，装上就能用，效果立竿见影。
7.2 问题二：你的团队技能栈是什么？
| 团队构成 | 推荐起点 | 理由 |
|---|---|---|
| 全是 Python 工程师，熟悉 FastAPI/SQLAlchemy | LangChain | 他们能快速理解Runnable和CallbackHandler，现有工程体系零改造接入。 |
| 产品经理主导，工程师资源紧张 | Pi | 产品经理写 YAML，工程师只需部署 Pi Server 和写几个custom插件，人力投入最小。 |
| AI Infra 团队强，有 GPU 运维经验 | DeepSeek Harness | 他们懂量化、懂 CUDA、懂显存管理，Harness 的 CLI 工具和参数调优，正是他们的主场。 |
| 开发者重度依赖 VS Code/JetBrains | Claude Code | 无需部署、无需学习新概念，装插件、登录账号、开用。ROI（投资回报率）最高。 |
7.3 问题三：你的长期演进路径是什么？
从 Pi 开始，逐步引入 LangChain：这是最平滑的路径。先用 Pi YAML 快速上线 MVP，验证业务逻辑；当某个
custom步骤越来越复杂（比如要加 RAG、要连 Kafka），就把它抽成一个 LangChain 微服务，Pi 通过 HTTP 调用。架构演进自然，无颠覆性重构。从 LangChain 开始，逐步接入 Harness：如果你的 LangChain 服务已经跑在 vLLM 上，但遇到性能瓶颈，可以把
LLM组件从ChatOpenAI换成ChatDeepSeekHarness（Harness 提供的 LangChain 兼容 wrapper），其他代码不动，性能提升立竿见影。Claude Code 是“终点”，不是“起点”：它不参与系统架构，只提升单点体验。你可以今天就装上，明天就受益，不影响任何其他技术选型。
最后分享一个血泪教训：我们最早做 PoC 时，试图用 LangChain 实现一个“YAML 工作流解析器”，想把 Pi 的能力搬到 LangChain 里。结果花了两周，只实现了 Pi 60% 的功能，还巨难维护。后来一拍脑袋：干嘛重复造轮子？直接用 Pi 做编排，LangChain 做能力，Harness 做执行。三天就上线了。有时候，承认“这个事就该用那个工具”，比证明“我能用这个工具做所有事”更专业。
