1. 从 Claude Code 到 Pi：一场关于 AI Coding 工具选择的真实迁移
最近半年，我身边做 AI Coding 的朋友圈子里，讨论话题明显变了。去年大家还在群里晒 Claude Code 的安装截图、比谁的 prompt 写得更优雅，今年画风一转，开始有人问“Pi 到底值不值得换”“pi agent 官网在哪”“harness 和 agent 到底啥区别”。我自己也是从 Claude Code 一路用到 Pi 的，中间踩过的坑、翻过的文档、重装过的环境，加起来能写一本小册子。所以这篇文章不打算做那种“官方文档翻译”式的介绍，而是想以一个真实迁移者的身份，把为什么越来越多人放弃 Claude Code 转而用 Pi 这件事，从技术选型、架构差异、实操体验、常见问题几个维度彻底讲清楚。
先说结论性的判断：这不是一次简单的“工具替换”，而是 AI Coding 从“单点对话式助手”向“可编排的 agent 执行框架”演进的一个缩影。Claude Code 解决的是“让 AI 帮我在终端里写代码”这个问题，而 Pi 加上 harness 这一套体系，解决的是“让 AI 按照我定义的规范、流程、多智能体协作方式，稳定地完成一整条开发链路”这个问题。前者是助手，后者更接近一个可编程的开发流水线。理解了这个本质差异，你就能明白为什么那些真正把 AI Coding 用进生产环境的团队，会逐渐把重心从 Claude Code 挪到 Pi 上。
这篇文章适合几类人看：一是已经在用 Claude Code，但感觉“用着用着就到瓶颈了”的开发者；二是刚接触 AI Coding，在 Claude Code、Pi、各种 agent 框架之间犹豫的新手；三是想搞清楚 harness、agent、多智能体协作这些概念到底怎么落地的人。我会尽量用生活化的类比把复杂概念讲透，同时给出可以直接抄作业的配置和步骤。不管你是刚装完 Claude Code 的小白，还是已经在折腾 deepseek harness 插件的老手，应该都能从里面找到对自己有用的东西。
2. 核心概念先理清：Claude Code、Pi、harness、agent 到底是什么关系
2.1 用“厨房”类比理解这四个概念
很多人一上来就被 Claude Code、Pi、harness、agent 这几个词绕晕了，其实用厨房来类比就特别清楚。Claude Code 像是一个厨艺很好的私人厨师，你告诉他“做个番茄炒蛋”，他就能给你做出来，味道还不错。但问题是，这个厨师一次只能做一道菜，而且他做菜的方式你没法标准化——今天咸一点明天淡一点，全看他当时的状态。这就是 Claude Code 的本质：一个能力很强但偏“对话式”的编码助手。
Pi 则更像是一个厨房管理系统。它本身不一定比那个厨师厨艺更好，但它定义了“谁买菜、谁切菜、谁炒菜、谁摆盘”这一整套流程。而 harness 就是这套流程的“操作台和规则手册”——它规定了每个环节的输入输出格式、失败重试机制、以及多个厨师之间怎么协作。至于 agent，就是厨房里的每一个具体角色，切菜 agent、炒菜 agent、尝味道 agent，各司其职。
这个类比的关键在于：Claude Code 的强项是“单兵作战能力”，Pi + harness 的强项是“体系化协作能力”。当你只是想让 AI 帮你写个函数、改个 bug，Claude Code 完全够用，甚至体验更顺滑。但当你需要 AI 按照团队规范、分步骤、可复现地完成一个完整功能模块，甚至多个 agent 并行处理不同子任务时，Pi 这套体系的优势就出来了。
2.2 harness 和 agent 的区别，一句话讲明白
热搜词里“harness和agent区别”出现频率很高，说明这是很多人的困惑点。我用一句话概括：agent 是干活的，harness 是管干活的。agent 是一个具备自主决策能力的执行单元，它能理解任务、调用工具、产出结果。harness 则是包裹在 agent 外面的那一层“执行框架”，它负责调度 agent、传递上下文、处理错误、记录日志、控制流程。
打个比方，agent 像是公司里的员工，harness 像是公司的管理制度和办公系统。员工能力再强，如果没有一套好的制度来协调，十个人干活可能还不如一个人。反过来，harness 设计得再好，如果 agent 本身能力不行，那也只是空转。所以 Pi 的竞争力，恰恰在于它把 harness 这一层做得足够开放和可编排，让开发者能自己定义 agent 的行为规范，而不是被锁死在某个固定的交互模式里。
2.3 为什么“可编排”是分水岭
Claude Code 的交互模式本质上是“你一句我一句”的对话。这种模式在探索性任务上很舒服，但在重复性、标准化任务上就很累。你得反复交代同样的规范，比如“记得用 TypeScript 严格模式”“错误处理要统一用我们的 logger”“测试文件放在tests目录下”。每次新开一个会话，这些上下文都得重新喂一遍。
Pi 的思路是把这些规范沉淀到 harness 配置里。你定义一次“代码生成规范示例”，之后所有经过这个 harness 的 agent 都会自动遵守。这就从“每次口头交代”变成了“写进制度里”。对于个人开发者，这可能只是省点事；但对于团队协作，这是质的区别——它让 AI 产出的代码质量变得可预期、可审计。
3. 为什么越来越多人放弃 Claude Code：五个真实痛点
3.1 痛点一：上下文窗口的“记忆焦虑”
用 Claude Code 时间长了，最明显的感受就是“记忆焦虑”。一个稍大的项目，你让它理解现有代码结构，它读着读着上下文就满了，然后开始“忘事”。你前面刚说过的规范，后面它就忘了。这不是 Claude Code 独有的问题，而是所有对话式 AI Coding 工具的通病。但在实际项目里，这个痛点会被无限放大——你不得不把任务拆得特别碎，碎到每次都能塞进上下文窗口，结果就是效率反而下降了。
Pi 的 harness 机制在这一点上的思路不同。它不追求让单个 agent 记住所有东西，而是通过 harness 在多个 agent 之间传递“结构化上下文”。比如一个 agent 负责读代码生成摘要，另一个 agent 拿着摘要去写新代码。每个 agent 的上下文都是精简过的，但整体信息不丢失。这就像接力赛，不是让一个人跑完全程，而是每个人跑自己那一棒，交接棒的时候把关键信息传下去。
3.2 痛点二：无法标准化，团队协作时“各写各的”
第二个痛点更致命，就是标准化问题。Claude Code 的产出高度依赖你当时的 prompt 质量。同一个需求，张三写出来的 prompt 和李四写出来的，产出的代码风格可能完全不同。在个人项目里这无所谓，但在团队里，这会导致代码 review 成本飙升。你没法要求每个成员都成为 prompt 工程专家，也没法保证大家每次都记得交代所有规范。
Pi 的 harness 允许你把“代码生成规范示例”固化下来。比如你可以定义一个 harness，规定所有生成的代码必须：使用项目的 ESLint 配置、函数必须有 JSDoc 注释、异步操作必须用 try-catch 包裹、新增依赖必须走内部 registry。这些规则写进 harness 后，不管是谁触发 agent，产出都符合规范。这就把“依赖个人经验”变成了“依赖系统约束”，是团队规模化使用 AI Coding 的前提。
3.3 痛点三：单 agent 能力天花板明显
Claude Code 本质上是单 agent 模式，一个模型面对所有任务。但实际开发中，不同任务需要的能力差异很大。写 UI 组件需要审美和组件库知识，写数据库迁移需要 SQL 和 schema 设计能力，写测试需要边界条件思维。让一个 agent 同时精通所有领域，效果必然打折扣。
Pi 支持多智能体协作，你可以针对不同任务配置不同的 agent。比如一个专门写 React 组件的 agent，一个专门写单元测试的 agent，一个专门做代码审查的 agent。它们通过 harness 串联起来，各司其职。这就像从“全科医生”变成了“专科医生会诊”，每个环节的专业度都上去了。热搜词里“多智能体 ai agent coding协助开发规范”能火，说明大家已经意识到单 agent 的局限了。
3.4 痛点四：错误处理和重试机制太原始
用 Claude Code 的时候，如果它生成的代码跑不通，你只能手动把错误信息贴回去，让它再改。这个循环有时候要重复好几次，而且每次都要你手动操作。更麻烦的是，如果它生成的代码有隐蔽的逻辑错误，你可能要过很久才发现。
Pi 的 harness 可以配置自动化的错误处理和重试逻辑。比如规定“如果 agent 产出的代码编译失败，自动把错误信息回传给 agent 并要求修复，最多重试三次”。这就把很多机械性的往返操作自动化了。热搜词里那个“agent execution terminated due to error”的报错，其实很多时候就是因为 harness 的重试策略没配好。配好了之后，这类问题会少很多。
3.5 痛点五：与现有工具链的集成不够灵活
Claude Code 虽然支持在 VS Code 里用，也支持终端，但它的集成方式相对固定。你想把它嵌进自己的 CI/CD 流程，或者和内部的代码审查系统打通，就比较费劲。而 Pi 的 harness 本质上是一个可编程的框架，你可以用代码定义它的行为，这就为深度集成打开了空间。
比如你可以写一个 harness，让 agent 在提交代码前自动跑一遍内部的安全扫描工具，扫描不通过就不允许提交。这种级别的定制，在 Claude Code 的对话模式下很难实现，但在 Pi 的框架下就是写几行配置的事。这也是为什么“harness engineering”这个概念开始被越来越多人讨论——它代表了一种把 AI Coding 工程化的思路。
4. Pi 的核心优势拆解：不只是换个工具那么简单
4.1 优势一：harness 让 AI Coding 变得可复现
可复现性是工程化的基石。Claude Code 的产出很难复现，因为同样的 prompt 在不同时间、不同上下文下，结果可能不一样。Pi 的 harness 通过固定 agent 的输入输出格式、固定工具调用顺序、固定上下文传递方式，让整个流程变得可复现。你今天跑一遍得到一个结果，明天用同样的配置跑一遍，结果应该是一致的。
这个特性在什么场景下最有用？答案是“需要审计和回溯的场景”。比如金融、医疗这类对代码变更有严格审计要求的行业，你需要能说清楚“这段代码是怎么被生成出来的、经过了哪些步骤、谁批准的”。Pi 的 harness 天然记录了这些信息，而 Claude Code 的对话记录很难做到这一点。
4.2 优势二：多 agent 协作带来的“专业分工”
前面提到多智能体协作，这里展开讲讲具体怎么落地。在 Pi 里，你可以定义一个“代码生成 agent”和一个“代码审查 agent”。生成 agent 负责根据需求写代码，审查 agent 负责检查代码是否符合规范、是否有潜在 bug。两个 agent 通过 harness 串联，生成 agent 的产出自动流转到审查 agent，审查不通过就打回重做。
这种模式的好处是，审查 agent 可以用不同的 prompt 策略，甚至不同的模型。比如生成用擅长创意的模型，审查用擅长逻辑分析的模型。这比让一个模型既当运动员又当裁判要靠谱得多。热搜词里“agent开发学习路线”热度高，说明很多人想学这个，但真正落地多 agent 协作的团队还不多，这中间有信息差，也有实践门槛。
4.3 优势三：与 deepseek harness 等生态的兼容性
Pi 的另一个优势是它的开放性。它不绑定某一个模型，你可以接 Claude，也可以接 DeepSeek，还可以接其他模型。热搜词里“deepseek harness”“deepseek harness插件”“deepseek harness安装”频繁出现，说明很多人在尝试把 DeepSeek 的能力接入 harness 体系。这种开放性让 Pi 成为一个“模型无关”的编排层，而不是某个模型的附属品。
这对开发者意味着什么？意味着你不会被单一模型供应商锁定。今天 Claude 效果好就用 Claude，明天 DeepSeek 性价比高就换 DeepSeek，harness 层的配置不用大改。这种灵活性在模型快速迭代的当下，价值非常高。Claude Code 虽然也支持换模型，但它的整体设计还是围绕 Claude 优化的，换模型的体验不如 Pi 这种原生多模型架构来得自然。
4.4 优势四：pi web 带来的可视化编排
Pi 还有一个被低估的优势是 pi web。它提供了一个可视化的界面来管理和编排 agent 流程。对于不习惯纯命令行操作的开发者，这个界面大大降低了上手门槛。你可以在网页上拖拽配置 agent 的先后顺序、设置每个 agent 的参数、查看执行日志。
这一点对团队推广特别重要。你让一个资深工程师去写 harness 配置没问题，但让产品经理或测试同学也参与进来，纯命令行就不现实了。pi web 让非技术角色也能理解 AI Coding 的流程，这对于推动整个团队拥抱 AI Coding 很有帮助。Claude Code 虽然有桌面版，但它的定位还是个人助手，不是团队协作平台。
5. 实操：从 Claude Code 迁移到 Pi 的完整步骤
5.1 环境准备与安装
迁移的第一步是环境准备。如果你之前装过 Claude Code，建议先卸载干净，避免环境变量冲突。卸载 Claude Code 的命令根据安装方式不同而不同，如果是 npm 全局安装的，用npm uninstall -g对应的包名即可。然后清理一下相关的配置目录，通常在用户主目录下的隐藏文件夹里。
安装 Pi 之前，确认你的 Node.js 版本。实测下来，Node 18 以上比较稳，Node 20 LTS 是最推荐的。如果你在 Ubuntu 上，可以用 nvm 来管理 Node 版本，这样切换起来方便。Windows 用户建议用 WSL2，原生 Windows 环境下有些依赖会有兼容性问题，我踩过这个坑，折腾了半天最后还是回到 WSL2。
# 确认 Node 版本 node -v # 如果低于 18，用 nvm 安装新版 nvm install 20 nvm use 20安装 Pi 本身通常通过 npm 或官方提供的安装脚本。安装完成后，运行初始化命令，它会引导你配置模型 API key、选择默认 harness 等。这一步别急着跳过，认真配好，后面省事。
5.2 配置你的第一个 harness
安装完 Pi 之后，最重要的一步是配置 harness。新手容易犯的错误是直接拿默认配置就用，结果发现效果一般，然后得出结论“Pi 不如 Claude Code”。其实问题出在没配好 harness。
一个基础的 harness 配置通常包含几个部分：agent 定义、工具权限、上下文传递规则、错误处理策略。我建议从最简单的单 agent harness 开始，先跑通一个“读需求→写代码→输出”的流程，然后再逐步加复杂度。
# 一个简化的 harness 配置示例 name: basic-coding-harness agents: - name: coder model: claude-sonnet system_prompt: | 你是一个资深工程师，遵循以下规范： 1. 使用 TypeScript 严格模式 2. 所有函数必须有 JSDoc 注释 3. 错误处理统一使用项目 logger tools: - read_file - write_file - run_test error_handling: max_retries: 3 on_failure: retry_with_error_context这个配置的关键在于system_prompt里固化了代码规范。这就是前面说的“把规范写进制度里”。配好之后，你每次让 agent 写代码，它都会自动遵守这些规范，不用你再重复交代。
5.3 接入 deepseek harness 的注意事项
如果你想用 DeepSeek 作为底层模型，需要额外配置。热搜词里“deepseek harness安装”和“deepseek harness插件”出现很多，说明这是大家关心的点。接入 DeepSeek 的关键是配置正确的 API endpoint 和模型名称。DeepSeek 的 API 格式和 OpenAI 兼容，所以大部分 harness 框架都能直接支持。
需要注意的是，不同模型对 prompt 的敏感度不同。Claude 对长 system prompt 的遵循度比较好，DeepSeek 可能需要你把规范写得更简洁直接一些。我实测下来，同样的 harness 配置，换成 DeepSeek 后需要微调 system prompt 的措辞，效果才能对齐。这不是模型好坏的问题，而是每个模型有自己的“脾气”，得顺着来。
5.4 在 VS Code 中集成 Pi
虽然 Pi 有 pi web，但日常写代码还是在 VS Code 里最顺手。Pi 提供了 VS Code 插件，安装后在侧边栏就能调用 agent。配置的时候注意把 harness 的路径指对，否则插件找不到你的配置。
如果你之前配过 VS Code 的 Claude Code 插件，迁移到 Pi 插件时要注意快捷键可能冲突。我建议先把 Claude Code 插件禁用，再装 Pi 插件，避免两个插件抢同一个快捷键。这个细节很小，但踩过的人都知道有多烦。
6. 常见问题与排查技巧实录
6.1 报错“response stream was malformed”怎么处理
热搜词里有个很具体的报错：“pi error: the response stream was malformed and no response was produced. try again.” 这个报错我遇到过几次，通常有几个原因。一是网络波动导致流式响应中断，这种情况重试一般能解决。二是模型 API 返回了非预期的格式，可能是模型端的问题，换个时间段再试。三是 harness 配置里的输出解析规则和模型实际输出不匹配，这个需要检查你的 harness 配置。
排查顺序建议是：先重试一次，如果还报错，检查网络，再检查 harness 的输出解析配置。如果都正常，可能是模型服务端的问题，等一会儿再试。我遇到的大部分情况重试就好了，少数情况是配置问题。
6.2 agent 执行中断的常见原因
“agent execution terminated due to error”这个报错也比较常见。原因通常有三类：一是 agent 调用的工具执行失败，比如读文件时文件不存在、跑测试时环境没配好；二是上下文超限，agent 处理到一半上下文满了；三是 harness 的重试次数用完了，agent 主动终止。
排查这类问题，关键是看日志。Pi 的 harness 会记录每个 agent 的执行步骤和中间状态。找到报错前最后一步在做什么，基本就能定位问题。如果是工具执行失败，检查工具配置；如果是上下文超限，考虑拆分任务或优化上下文传递；如果是重试耗尽，看看是不是任务本身太难，需要拆成更小的步骤。
6.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决建议 |
|---|---|---|---|
| response stream malformed | 网络波动/输出解析不匹配 | 检查网络和 harness 解析配置 | 重试，或调整输出解析规则 |
| agent execution terminated | 工具失败/上下文超限/重试耗尽 | 查看执行日志定位最后一步 | 修复工具配置或拆分任务 |
| 生成代码不符合规范 | system prompt 不够明确 | 检查 harness 的规范定义 | 把规范写得更具体，加示例 |
| 多 agent 协作卡住 | 上下文传递格式不对 | 检查 agent 间数据格式 | 统一输入输出格式定义 |
| 模型响应慢 | 模型负载高/网络延迟 | 换时间段或换模型 | 配置备用模型 |
6.4 几个我踩过的坑
第一个坑是“过度配置”。刚用 Pi 的时候，我恨不得把所有能配的都配上，结果 harness 复杂到自己都看不懂，出了问题根本没法排查。后来学乖了，从最简配置开始，跑通了再加东西。这个原则适用于所有工程实践，但在 harness 配置上尤其重要，因为它涉及多个 agent 的交互，复杂度是指数级增长的。
第二个坑是“忽视日志”。Pi 的日志很详细，但很多人不看，出了问题就瞎猜。我现在的习惯是，每次配置完新 harness，先跑一个简单任务，把日志从头到尾看一遍，确认每个环节都符合预期。这个习惯帮我省了很多排查时间。
第三个坑是“模型和 harness 不匹配”。前面提过，不同模型对 prompt 的敏感度不同。我一开始拿 Claude 的 harness 配置直接套 DeepSeek，效果差很多，还以为是 DeepSeek 不行。后来调整了 system prompt 的写法，效果就上来了。所以换模型的时候，harness 配置一定要跟着调。
7. 多智能体协作的进阶玩法
7.1 设计一个“生成-审查-修复”闭环
当你熟悉了单 agent harness 之后，可以尝试多 agent 协作。最实用的一个模式是“生成-审查-修复”闭环。生成 agent 负责写代码，审查 agent 负责找问题，修复 agent 负责改问题。三个 agent 通过 harness 串联，形成一个自动化的质量保障流程。
这个模式的关键在于审查 agent 的 prompt 设计。审查 agent 不能太宽松，否则起不到把关作用；也不能太苛刻，否则会陷入无限修复循环。我的经验是，审查 agent 只关注“硬性规范”和“明显 bug”，比如类型错误、未处理的异常、违反项目规范的写法。至于代码风格偏好这种主观的东西，不要交给审查 agent，否则它会一直挑刺。
7.2 用 harness 实现“并行开发”
另一个进阶玩法是并行开发。比如一个功能需要同时改前端和后端，你可以配置两个 agent 并行工作，一个负责前端，一个负责后端，harness 负责协调它们的接口约定。这比串行开发快很多，但前提是接口约定要提前定义清楚，否则两个 agent 各写各的，最后对不上。
实现并行开发的关键是 harness 的“同步点”设计。两个 agent 在关键节点需要同步，比如接口定义完成后，两个 agent 都要基于这个定义继续工作。harness 要能处理这种同步逻辑，确保不会出现一个 agent 已经写完了，另一个还在用旧接口的情况。
7.3 多 agent 协作的注意事项
多 agent 协作虽然强大，但坑也不少。第一个注意事项是“上下文传递要精简”。agent 之间传递的上下文不是越多越好，太多会导致接收方 agent 上下文超限，太少又会导致信息丢失。我的经验是，只传递“决策所需的最小信息集”，比如接口定义、数据结构、关键约束，而不是把整个代码库都传过去。
第二个注意事项是“错误处理要统一”。多个 agent 协作时，错误处理逻辑如果不统一，很容易出现一个 agent 报错了，另一个 agent 还在傻等的情况。harness 要定义统一的错误传播机制，确保任何一个 agent 出错，整个流程都能正确响应。
第三个注意事项是“别过度设计”。多 agent 协作适合复杂任务，简单任务用单 agent 就够了。我见过有人为了用多 agent 而用多 agent，结果一个简单的 CRUD 功能搞了五个 agent，维护成本比收益还高。工具是为人服务的，别本末倒置。
8. 关于 AI Coding 代码质量的真实思考
热搜词里有个问题很扎心：“ai coding的到来会不会让代码质量下降”。这个问题我被问过很多次，我的答案是：取决于你用 AI Coding 的方式。如果你把 AI 当成“帮我快速堆代码”的工具，那代码质量大概率会下降，因为 AI 生成代码的速度远快于人类审查的速度，堆积的代码越多，质量越难保证。
但如果你把 AI Coding 当成“可编排的工程流程”，情况就反过来了。Pi 的 harness 机制恰恰是在解决这个问题——它通过规范约束、多 agent 审查、自动化测试，让 AI 生成的代码质量变得可控。关键不在于 AI 能不能写出好代码，而在于你有没有建立一套机制来保证它写出好代码。
我自己的实践是，所有经过 harness 的代码，都必须通过三道关：第一道是生成 agent 自身的规范约束，第二道是审查 agent 的检查，第三道是自动化测试。三道关都过了，代码才能进入人工 review 环节。这套流程跑下来，AI 生成的代码质量反而比纯人工写的更稳定，因为人工写代码会累、会走神、会偷懒，而 harness 不会。
当然，这套机制的建设成本不低。你需要花时间定义规范、配置 harness、调试 agent。但这是一次性投入，建好之后，后面所有任务都受益。这也是为什么我最终选择从 Claude Code 迁移到 Pi——Claude Code 让我体验到了 AI Coding 的“爽”，而 Pi 让我体验到了 AI Coding 的“稳”。爽是一时的，稳才是长期的。
9. 给不同阶段开发者的迁移建议
如果你是完全的新手，刚接触 AI Coding，我的建议是先用 Claude Code 熟悉基本概念。Claude Code 的上手门槛低，交互直观，适合建立对 AI Coding 的感性认识。用一段时间，等你感觉到“每次都要重复交代规范很烦”“单 agent 处理复杂任务力不从心”的时候，再考虑迁移到 Pi。
如果你是有一定经验的开发者，已经在用 Claude Code 做实际项目，我的建议是“渐进式迁移”。不用一下子全换，可以先在某个子项目上试 Pi，跑通一个完整的 harness 流程，积累经验后再推广到其他项目。迁移过程中，把 Claude Code 里常用的 prompt 整理成 harness 配置，这样过渡会比较平滑。
如果你是团队的技术负责人，想推动团队用 AI Coding，我的建议是“先建规范，再上工具”。Pi 的 harness 威力在于它能固化规范，但前提是你得有规范。如果团队本身没有代码规范，那上什么工具都白搭。先把规范梳理清楚，再用 harness 把它固化下来，这样 AI Coding 才能真正提升团队效率，而不是制造混乱。
10. 我个人的一些实操心得
用 Pi 这段时间，最大的体会是“配置即文档”。以前团队的代码规范写在 wiki 里，没人看。现在写进 harness 配置里，每次 AI 生成代码都会遵守，久而久之大家反而记住了。这算是意外收获——AI Coding 工具倒逼团队把规范落地了。
另一个心得是“从小处着手”。别一上来就想搞一个覆盖全流程的复杂 harness，先从一个小环节开始，比如只做代码格式化，跑顺了再加代码审查，再加测试生成。每加一个环节，都要确保它真的带来价值，而不是增加复杂度。我见过太多团队搞了一套巨复杂的 agent 流程，最后没人用，因为维护成本太高。
最后一个心得是“保持怀疑”。AI Coding 工具再强，它也是工具。它生成的代码，你得看懂、得能改、得能负责。我见过有人完全信任 AI 生成的代码，连看都不看就提交，结果出了线上事故。工具可以帮你提效，但不能替你负责。这个边界，任何时候都不能模糊。
关于 Pi 和 Claude Code 的选择，我的最终建议是：如果你追求的是“个人效率的极致提升”，Claude Code 依然是很优秀的选择；如果你追求的是“团队协作的工程化落地”，Pi 加上 harness 体系更值得投入。两者不是替代关系，而是适用场景不同。我自己现在是两个都用，简单任务用 Claude Code，复杂流程用 Pi，各取所长。工具是死的，人是活的，找到适合自己的组合才是最重要的。
