ECC Research Mode 研究模式实战：用 `research-mode` 规范技术选型与架构决策

2026-09-06 18:51:46作者：管翌锬

The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.

项目地址：https://gitcode.com/GitHub_Trending/ev/ECC

导读

在 Claude Code、Codex、Kiro 等 AI 编程智能体日渐深度参与技术选型与系统设计的今天，"如何让智能体像资深工程师一样带着评估框架做研究"成为决定决策质量的关键。本指南以 .kiro/steering/research-mode.md 为骨架，完整讲解 ECC（Everything Claude Code）Agent Harness 中的 Research Mode（研究模式）：它如何通过一条 #research-mode 指令激活一套"先研究、后结论"的上下文，从研究流程、六大评估准则到结论沉淀逐层规范智能体的调研行为。读完本文，你将掌握在任何 ECC 兼容项目（含 .kiro/ 目录结构）中按需加载研究上下文的原理、一套可直接套用的多维度技术评估清单，以及如何把研究结论转化为可供架构决策引用的记录。

一、Research Mode 是什么：一种"按需注入"的智能体上下文

在 ECC 与 Kiro 的上下文体系统中，.kiro/steering/ 目录下的文件被称作 steering files（导向文件），用于"提供常驻规则与上下文，塑造智能体与你代码协作的方式"（见 .kiro/README.md）。它们按加载方式分为三类：

加载方式	说明	典型文件
`inclusion: auto`	每次会话自动加载，无需任何动作	`coding-style.md`、`security.md`、`testing.md`
`fileMatch`	匹配到指定文件类型时自动加载	`typescript-patterns.md`（`.ts,.tsx`）、`python-patterns.md`（`*.py`）
`inclusion: manual`	仅在显式调用时注入，不污染普通会话	`dev-mode.md`、`review-mode.md`、`research-mode.md`

research-mode.md 的 YAML frontmatter 开门见山：

---
inclusion: manual
description: Research mode context for exploring technologies, architectures, and design decisions
---

即它属于 manual（手动）型 steering 上下文，定位是"探索技术、评估方案、做架构与设计决策"时使用的专用语境。这类设计刻意避免把研究类长篇规则混入每一次普通对话——正如 README 所总结的："Manual steering files provide context-specific instructions without cluttering every conversation"（手动导向文件提供上下文专属指令，同时不干扰每次对话）。同一机制下还有面向开发实现的 dev-mode.md 与面向代码评审的 review-mode.md，三者共同构成"开发—评审—研究"的按需上下文矩阵。

二、触发与适用时机：何时、如何进入 Research Mode

根据文档末尾的 Invocation 段，激活方式只有一种：

Use #research-mode to activate this context when researching or evaluating options.

在支持 Kiro steering 调用的会话中直接输入 #research-mode（或 > #research-mode），即把研究模式上下文注入当前对话。文档首段同时明确了适用场景与边界：

研究（research）技术、评估（evaluate）候选方案、或者进行架构与设计决策（making architectural decisions）；
一句话使用原则："Use this context when researching technologies, evaluating options, or making architectural decisions."

仓库根目录的通用研究语境 contexts/research.md 用一句话概括了这一模式的整体气质："Mode: Exploration, investigation, learning / Focus: Understanding before acting"（探索、调查、学习，先理解再行动），并强调 "Don't write code until understanding is clear"（理解未清晰前不写代码）。因此 Research Mode 适合在两种时刻进入：一是面对"用什么技术/选哪个方案"的开放性问题时（选型前）；二是对陌生代码库或新技术领域"先摸清全貌"时（动手实现前）。

三、研究流程六步：从模糊问题到清晰结论

research-mode.md 规定了标准研究过程，这是把一次开放式调研收敛为结构化产出的主干流程：

Define the problem or question clearly —— 清晰地定义问题或待回答的问题；
Identify evaluation criteria —— 识别评估准则（通常直接复用下文六大维度，或按场景裁剪）；
Research available options —— 研究可用的候选方案；
Compare options against criteria —— 用准则逐一横向对比各候选方案；
Document findings and recommendations —— 记录发现与建议；
Consider trade-offs and constraints —— 审视取舍与约束条件。

不难看出，这六步把"研究"拆成了"提问 → 立标尺 → 收集 → 比对 → 成文 → 复盘约束"的闭环。值得强调第 1 步与第 6 步常常被省略却又最关键：第 1 步决定了后续搜索与对比的方向，第 6 步则把结论从"纸上对比"拉回"当前项目的真实约束"（如团队熟悉度、现有技术栈兼容性、运维成本承受力）。这与 ECC 生态中的 deep-research 技能的工作流同构——后者同样以"拆解 3-5 个子问题 → 多源检索 → 深读关键源 → 综合成文"推进，说明"先结构化提问再动手检索"是 ECC 系列研究型能力的一致基因。

四、六大评估准则详解：可复用的多维度决策标尺

文档的主体是一个分六个类别的评估框架，每类下都有一组自检问题。这套清单既可用于技术选型，也可用于架构取舍，是本文最值得"原样带走"的部分。

4.1 技术契合度（Technical Fit）

Does it solve the problem effectively? —— 它能否有效解决问题？
Is it compatible with existing stack? —— 与现有技术栈是否兼容？
What are the technical constraints? —— 存在哪些技术约束？

契合度永远是第一道闸门：一个再优秀的方案，若与现有栈冲突或无法满足硬性约束，就不应进入下一轮。评估时建议把"功能需求满足度"与"约束匹配度"分开打分，避免被单个亮点带偏整体判断。

4.2 成熟度与支持（Maturity & Support）

Is the technology mature and stable? —— 技术是否成熟稳定？
Is there active community support? —— 是否有活跃的社区支持？
Is documentation comprehensive? —— 文档是否全面？
Are there known issues or limitations? —— 是否存在已知问题或局限？

成熟度考察的是"坑的可见性"：文档全面、issue 公开可查、社区活跃的项目，风险更可预期。判断依据应来自真实证据（release 节奏、issue tracker、文档覆盖度），而非口号式宣传。

4.3 性能与可扩展性（Performance & Scalability）

What are the performance characteristics? —— 性能特征如何？
How does it scale? —— 如何扩展？
What are the resource requirements? —— 资源需求是什么？

对性能类问题，文档要求"Include relevant benchmarks or comparisons"（附上相关基准或对比），因此凡涉及性能论断，应优先引用官方 benchmark 或可复现的实测，而不是凭印象下结论。

4.4 开发者体验（Developer Experience）

Is it easy to learn and use? —— 是否易于学习与使用？
Are there good tooling and IDE support? —— 是否有良好的工具链与 IDE 支持？
What's the debugging experience like? —— 调试体验如何？

开发者体验直接影响团队落地速度与长期维护意愿。工具链（类型定义、插件、调试器）完备程度与学习曲线，常是中小团队选型中最实际的权重项。

4.5 长期存活性（Long-term Viability）

Is the project actively maintained? —— 项目是否在积极维护？
What's the adoption trend? —— 采用趋势如何？
Are there migration paths if needed? —— 若需迁移，是否有迁移路径？

"有没有退路"是这组问题的点睛之笔：即使当下方案合适，也要预先确认被替代/迁移的成本，这是架构决策中典型的"第二层思考"。

4.6 成本与许可（Cost & Licensing）

What are the licensing terms? —— 许可条款是什么？
What are the operational costs? —— 运营成本是多少？
Are there vendor lock-in concerns? —— 是否存在厂商锁定隐忧？

许可与成本问题在商业化场景下常具一票否决权，需结合项目实际部署形态（自托管/云托管、商用/开源）核实条款，而非只看 README 首屏。

五、文档产出规范：让研究结果可引用、可追溯

research-mode.md 的 Documentation 一节明确要求，研究结束后产出物必须达到"可供他人与后续会话引用"的质量：

Document decision rationale —— 记录决策依据（为什么选它，而不是只记录结论）；
List pros and cons of each option —— 逐项列出每个方案的利弊；
Include relevant benchmarks or comparisons —— 附上相关基准测试或横向对比；
Note any assumptions or constraints —— 注明假设与约束；
Provide recommendations with justification —— 给出带理由的建议。

这与根目录 contexts/research.md 的输出原则 "Findings first, recommendations second"（先摆事实、再给建议）互相呼应：研究产出应当让读者先看到证据链，再看到基于证据的推荐。同时可借用 deep-research 技能的成熟做法来强化可信度：每条论断标注来源、单源信息标注"未经验证"、把事实与推断/预估明确区分、找不到数据时如实说明——这些规则可以原样移植到 Research Mode 的结论记录中。

六、仓库机制佐证：steering 文件如何被创建与加载

理解 Research Mode 背后是 ECC/Kiro 对 steering 文件的一整套加载约定（见 .kiro/README.md）：

inclusion: auto 的导向文件"load automatically"，安装即生效、无需任何动作；
inclusion: manual 的文件需显式指令触发，research-mode.md、dev-mode.md、review-mode.md 均属此类；
想要扩展自己的模式，只需向 .kiro/steering/ 添加带 frontmatter 的 Markdown 文件即可，官方模板为：

---
inclusion: auto            # auto | fileMatch | manual
name: my-steering          # inclusion 为 auto 时必填
description: Brief explanation of what this steering file contains
fileMatchPattern: "*.ts"   # inclusion 为 fileMatch 时必填
---

Your rules here...

安装层面，.kiro 目录通过 install.sh 一次性注入项目（./install.sh /path/to/your/project），采用非破坏性复制，不会覆盖已有文件，且"所有文件安装后均可自行修改"，因此在 .kiro/steering/research-mode.md 中增删评估维度、加入团队专属选型红线（如"禁止引入 AGPL 许可依赖"）都是安全的定制方式。

七、与周边能力协同：把"研究模式"放进研发闭环

Research Mode 不是孤立的一次性上下文，它天然服务于 ECC "research-first development"（研究先行式开发）的总体定位——这一定位也体现在项目多语言文档中（如 README 所述 ECC 涵盖 skills、instincts、记忆优化、持续学习、安全扫描与研究先行的开发方法论）。将其置于完整工作流中，可与以下仓库内能力形成闭环：

配合 #review-mode / #dev-mode：同属 .kiro/steering/ 的手动模式，研究产出经 #review-mode 复核、再进入 #dev-mode 实现，形成"研究→评审→开发"的上下文切换链；
配合 deep-research 技能：当问题需要联网多源求证（竞品分析、行业现状、技术趋势）时，激活 .kiro/skills/deep-research/SKILL.md 补充外部证据，其"每条论断必须有来源"的质量规则能补足 Research Mode 在事实核查上的颗粒度；
配合 search-first 技能：在选型接近落地时，.kiro/skills/search-first/SKILL.md 的决策矩阵（Adopt/Extend/Compose/Build）为"要不要引入新依赖"提供收尾裁决——先确认是否已有现成库或 MCP，避免重复造轮子；
配合 planner / architect 类智能体：研究阶段的候选清单与评估表，可直接作为后续规划与架构设计会话的输入上下文，避免下游重复调研。

从源码结构推断，.kiro/agents/ 下的 planner、architect 等 agent 均以只读工具为主、面向分析与规划（见 .kiro/README.md 中 agent 清单描述），恰是 Research Mode 结论的理想消费方——研究先行、决策有据，正是这套 Harness 想固化的工程习惯。