Experience
构建产品的总体思路
为整体框架留出容错性与可扩展性
设计整体框架时，需要具有一定的容错性和可扩展性，避免后续添加新组件或功能时带来麻烦。
实例 & 分析CN-travel-MCP · 模块组织
实例
构建 CN-travel-MCP 时，没有将不同模块的工具统一集中展示给 agent，而是以模块为单位，分别展示模块内部的工具。
问题 & 分析
两者在给 agent 的形式呈现上基本没有差别，但以模块组织工具，让开发者可以相对自由、方便地嵌入新模块，并对模块内的工具实现自定义调整。
不要尝试一口气完成全部产品功能
即便借助 agent，即便只是前端效果，也不要尝试一次完成全部功能构建。
一口气开发的问题
- 组件间冲突难以定位。不同模块发生冲突时，无论人类还是 agent，都难以定位关键问题出在哪里。
- 解决方案不可控。在大项目中，agent 可能只给出局部解决方案，例如针对测试场景打补丁，而没有真正解决核心问题。
- 跑通之后仍然难以调优。无法区分问题来自组件间的协同，还是组件本身。
基本原则
先跑通最小 demo 或主干流程，再考虑输入输出的约束限制，以及效率提升（例如提高文档阅读效率）。
划分最小组分时，应只包含核心模块，暂不加入其余的校准、验证等模块。
难点：多大程度上才算适合 agent 开发的模块？这需要工程开发经验，以及对 agent 能力的感知。
方法：采用瀑布开发，先做出包含核心功能和基本布局的 demo，逐步测试每个功能的完备性，而后逐步拓展。
实例 & 分析Autoresearch 插件 · 开发范围
实例
对于自己的 autoresearch 插件，初步设想是三步走：
- 对 idea 进行可控打磨。
- 结合数据库与论文语言标准化，实现 idea 自动构建。
- 结合下游的具体代码实现与实验结果，打通链路。
问题 & 分析
在构建第一步的过程中，我希望约束 research contract，以编程形式强制设置检查点，并设立安全防御机制等。这些构想带来了过大的工程量。
即便借助 GPT-6-Astra max 高强度运行并得到插件，最终仍因 token 消耗和不同模块间的潜在冲突，造成插件难以使用，问题也难以准确定位。
- 尤其是需要让 agent 自行定位 harness 中的问题时。
针对不同模块
Skill 构建：独立职责与流程编排
原则上，不同 skills 应相对独立，避免冲突。对于联合多个 skill 构建的流程，应采用1 个流程 skill + n 个独立 skill的形式。
然而，在实际体验中，根据用户的实际需求，通常并不期待独立 skill 执行完后直接停止，而是希望它继续执行后续的默认任务，或至少以提问的形式，请用户给出反馈或确认。这可以通过 system prompt（例如 rules / AGENTS.md）来约定。
- 好处
- Skill 相对隔离，边界明确。
- 整体流程易于管理，尤其是相对固定的多链调用，方便控制和调整。
- 代价
- 流程中心化。底层的机动性可能不足，例如限制了 agent 自主组合流程的能力。
- 长上下文中的流程错误。上下文过长时，LLM 可能因 attention 失败而出现流程错误。
- 无效的上下文占用。后续流程未必会实际执行，却已占用上下文；这一影响相对较小。
Agent trajectory：关注中间执行过程
除了最终是否执行成功，还要关注中间流程是否有效、直接，包括以下两个方面：
- 效果
- 反复失败的工具调用，以及由此造成的大量工具原始代码读取。
- 效率
- 在 thinking 中，纠结于不必要的工具或 skill 选择。
- 目标是读取文档中的特定内容，最终却读取了整份文档。
细节
异常行为监测
单一行为（固定步幅、固定间隔）会在服务端行为分析里聚成异常簇；每个动作加一层独立随机源，分布就被打散成“真人噪音”。
主干内容处理完后，仍需真实执行与人工打磨
- 拿真实实例执行。启动完成后，即便 unit tests 已经通过，仍需要真实执行，才能触发各种可能的边界条件。
- 逐项抠细节。效率、美观、修改前后的一致性等，都需要人工一点一点检查与调整。
其他思考
自主性与可控性之间的权衡
人类在设计产品或框架时，需要权衡 agent 的自主性与 workflow 的固定可控性。
Agent 的自主性，模糊了“用户”与“开发者”的边界
Agent 的自主性允许“用户”和“开发者”在一定程度上不再严格区分，从而使开发者在一定程度上不必考虑用户端的呈现形式。
对开发者而言，需要重新考量 agent 需要什么，并重新思考惯常操作中不同设计细节的合理性。例如：
- 查询时，
--limit等参数是否需要设置，又该如何设置？ - 官方应提供怎样的 skills，来辅助用户调整结果的呈现？
实例 & 分析买票 · 中转联程策略
对于买票时的中转联程策略，agent 可以根据用户的个体需求，自行设计不同算法。这部分可以交给用户的 agent 根据需求实现，而不必全部由开发者预先设计。
先做市场调研，也要真实试用
构建产品前，优先做好市场调研，尤其要关注 GitHub 上的个人开发者，避免重复造轮子。
同时，需要真实试用，才能知道现有方案的效果，判断是否值得改进，以及哪里需要改进，而不是简单地接受或拒绝。梳理好自己的产品优势和产品定位后，再开始具体执行。
实例 & 分析CN-travel-MCP / paper-polish-product
实例
构建 CN-travel-MCP 和 paper-polish-product 前，我没有进行详细调研，仅仅考察了市面上大厂的产品是否存在、是否满足需要，简单考察后就直接执行。
问题 & 分析
- 完成后需要写总结报告时，才发现 GitHub 上已经有比较多类似产品。虽然采用的技术路径不完全相同，但都强烈依赖 agent 的自主性，没有显著差别。
- 实际使用时发现，部分官方 API（例如飞猪 API 和美团 API）返回的信息并不完整；加上我在设计之初就不计划加入规划功能，只提供信息接口，使得自己的产品在这里具有一定差异性。
这完全是自己的幸运，也是让人尴尬的幸运。
Tools、MCP、Skills 与 Harness：选择什么载体？
作为面向 agent 开发的产品，究竟应该选择怎样的载体？
- MCP
类似专业工具集合，适合作为工具箱。由于用户通常需要和服务器连接，才能获取工具列表及描述，这为开发者调整工具提供了便利。
- Skills
面向执行某项任务的具体流程，目标是减少由于 agent 缺少外部知识而造成的流程错误或效率低下。
Skills 一旦下载和确认，往往不会主动更新。尤其与 Python packages 不同，自然语言的形式很难准确定位不同 skills 之间的冲突。它们会在用户电脑上相对长期存在，因此不应作为可变的工具接口。
目前 agent 发展迅猛，工具本身的构建形式很可能发生转变。在这个时期，部分大厂为了蹭上 skills 的热点，以及利用其简单易用性，通过 skills 来充当工具接口，很难不让人认为是一个错误。