摘要

过去两周，我们小组围绕 MarketClaw——“你的私人产品营销助理”这一实训目标，从四个关键方向并行推进技术探索。许泽榕深入语言模型底层原理，为团队夯实了 Transformer 架构与 Tokenizer 的理论地基；张桐完成了 DeepSeek API 在营销场景下的能力验证，沉淀了首个可复用提示词模板；张垿赫对 nanobot 智能体框架进行了模块级拆解，输出了与项目需求的映射方案；商玉雷则打通了 MCP 协议与小红书平台的工具调用链路，并完成了一轮完整的故障定位分析。本文将按技术深度，记录我们在这一阶段的进展与认知。

 一、大模型底层认知建设(许泽榕)

在项目启动之初，我们意识到：如果只停留在 API 调用层面，后续的模型调参与业务优化将缺乏理论支撑。许泽榕因此承担了 LLM 底层原理的系统梳理工作。

一：Next Token Prediction 是能力涌现的根基。 语言模型本质上是一个“猜词”机器——每次只预测下一个 Token，通过海量文本上的不断纠错，统计规律中涌现出语法、常识甚至逻辑推理能力。理解这一点，让我们对 Prompt Engineering 与 Fine-tuning 的边界有了更清晰的判断：前者是在引导已学到的统计分布，后者是在修正分布本身。

二：Self-Attention 的数学根基。我们重点拆解了 Transformer 最核心的 Self-Attention 机制。其中，一个极易被忽略的细节是 除以sqrt(dk​)：若不进行缩放，高维向量点积的结果会过大，导致 softmax 输出趋近于独热分布，梯度消失，训练崩溃。本质上，这一步将点积结果的方差重新拉回 1，保证了 softmax 的“温和性”与梯度的健康流动。此外，Causal Mask 通过下三角掩码将未来位置的注意力权重归零，是实现自回归生成的必要约束。

三：Tokenizer 是参数预算的第一道阀门。以 MiniMind 为例，其词表仅 6400，远小于主流大模型的数万甚至十余万。原因在于：小模型总参数仅 64M，若词表过大，Embedding 层与输出层将吞噬大部分参数，留给 Transformer 核心层的预算所剩无几。这一认知让我们理解到：架构设计从头到尾都是资源约束下的权衡。

四：位置编码的演进逻辑。从绝对位置编码的“无法外推”缺陷，到 RoPE 通过旋转编码使注意力分数天然只依赖相对距离，再到 rope_theta 参数对有效序列长度的调控——位置编码的演进史，本质上是在回答“如何让模型处理比训练时更长的文本”这一工程难题。

这些理论储备，为团队后续可能涉及的模型微调与超参调整，提供了可追溯的分析框架。

二、DeepSeek API 能力验证与提示词工程(张桐)

技术选型上，我们放弃了大而全的模型对比，直接以工程需求为导向做决策。 DeepSeek 入选的理由非常务实：API 完全兼容 OpenAI 格式，意味着现有生态工具零成本接入；原生支持response_format强制输出合法 JSON，这对程序化解析至关重要；SSE 流式响应是飞书机器人“打字机效果”的技术前提；而成本指标对学生项目预算友好。

实验结论方面，我们围绕三个维度展开：

1. 商品信息提取（temperature=0.1，JSON 模式）：输入自然语言描述，模型稳定输出包含商品名称、品类、核心卖点的结构化 JSON，字段完整度达 100%（初步测试）。这验证了任务书“准确率 ≥95%”的可行性边界。

2. 文案生成与温度参数：对比 temperature=0.3 与 0.8 的输出，我们观察到一个重要现象——高温度并未带来显著的创意跃升，仅措辞微调。这说明：对文案风格的控制力，核心来自 System Prompt 的设计，而非单纯拉高温度。这为后续提示词优化指明了方向。

3. 流式交互验证：确认 SSE 机制满足实时交互的性能要求。

工程化沉淀上，测试通过的 System Prompt 已按功能分类，上传至 Gitee 仓库的 `prompts/` 目录，并附有参数建议（商品提取：temperature=0.1, max_tokens=300；文案生成：temperature=0.6-0.8）。这些模板将成为 Skill1 业务逻辑代码的直接输入。

三、nanobot 智能体框架学习(张垿赫)

nanobot 的架构给我们最大的启发在于模块化拆分与事件驱动的解耦设计。其核心源码目录nanobot/将 AI 助手拆解为职责清晰的几个模块：

①agent：承担意图识别、任务规划与工具调度的“大脑”角色。

②bus：所有模块通过消息总线间接通信，完全解耦。

③channels：统一不同消息渠道的输入输出格式。

④skills：每个技能独立目录、可插拔，正是我们五大营销技能（商品分析、热点追踪、文案生成、自动发布、评论回复）的理想组织形式。

⑤session：负责多轮对话的上下文管理与会话隔离。

当前阶段，我们已完成了 nanobot 模块与 MarketClaw 需求的映射，初步明确了各 Skill 的职责边界。这一方向的推进为小组分工开发提供了清晰的技术约束——每个人可以围绕自己负责的 Skill 独立开发，最终通过统一的消息总线集成。

四、MCP 协议与外部平台工具集成(商玉雷)

技术栈构成：xiaohongshu-mcp（Go 语言 MCP 服务端，将小红书功能抽象为 13 种 MCP 标准工具，覆盖内容发现、消费和社交互动三个域）+ MCPorter（Node.js 协议客户端，负责会话管理）+ OpenClaw（AI 控制框架，提供工具发现与注入）。

已完成的关键步骤：

1. 在 Windows 环境下完成 xiaohongshu-mcp 服务部署与 Cookie 认证态持久化。

2. MCPorter 成功完成协议初始化握手，工具列表元数据获取正常，RTT 约 0.1s。

3. OpenClaw 配置生效后，MCP 工具自动注入模型上下文，验证了声明式插件的可行性。

核心技术问题分析：

第一个问题暴露在协议理解层面。当我们直接用 curl 向 /mcp 端点发送tools/call请求时，服务端返回错误：method "tools/call" is invalid during session initialization。这一错误的根因在于 MCP 并非无状态的 RESTful API，而是基于 JSON-RPC 2.0 的有状态会话协议，必须严格遵循 initialize → initialized → Ready的状态迁移顺序。这是一个典型的“对协议状态机理解不足”导致的调用失败，也让我们深刻认识到在集成协议栈时，理解其状态模型比实现 API 签名更重要。

第二个问题更为棘手：search_feeds工具调用在 60s 超时阈值后失败。我们逐一排查了服务进程状态、端口监听、工具发现能力、Cookie 有效性、基础网络连通等因素，均未发现异常。初步定位将根因指向小红书 API 自身的响应延迟与可能的频率限制；更深层的分析则指向 xiaohongshu-mcp 基于 Go net/http标准库的默认 HTTP Client 未设置超时参数，导致在长链路场景下阻塞于数据读取阶段。

这一方向的实践让我们收获了一条重要认知：将 AI 能力延伸到外部平台时，协议栈的正确实现只是第一关，外部的反爬策略、网络不确定性、以及调用链各环节的超时控制策略，才是决定系统稳定性的关键。

五、团队技术认知与下一步计划

综合两周的探索，我们在以下维度形成了初步共识：

1. 底座模型已定：DeepSeek 在中文营销场景、JSON 约束、成本控制上综合表现符合预期，可作为统一底座。

2. 架构路径清晰：以 nanobot 的模块化 + 事件总线为参考蓝本，五大 Skill 插件化设计，bus 解耦。

3. 协议标准化是扩展性的核心保障：MCP 实验证明，标准化的工具接口与状态管理，能让 Agent 以“发现—约束—调用”的方式对接外部能力，这对后续接入更多平台具有范式意义。

4. 工程复杂性不容低估：从 MCP 超时到温度参数调校，从 Tokenizer 参数预算到 RoPE 外推，实际开发的复杂性分布在技术栈的每一层。

以上是我们第一阶段的技术日志。接下里的两周，各条线将进入更深层的实现阶段。

相关链接：
团队博客：https://blog.csdn.net/2401_83356673?type=blog
Gitee 仓库：https://gitee.com/cusir666/MarketClaw
成员个人博客：
  张桐：https://blog.csdn.net/2401_83356673?type=blog
  张垿赫：https://blog.csdn.net/x8688888?type=blog
  商玉雷：https://blog.csdn.net/2401_84216163?type=blog
  许泽榕：https://blog.csdn.net/2301_79938092?type=blog