企业官网建设流程全解析

说实话，我一开始也没想到能把这事跑通。

事情是这样的：我平时在电脑上用得最多的就是 DeepSeek Harness，它把模型调用、提示词模板、上下文管理、工具函数这些东西全封装成了一条顺畅的工作流。每次在终端里敲两下就能唤起整个 AI 管线，体验确实很爽。但问题也明显——我总不能天天背着笔记本。地铁上、咖啡馆里、出差路上，很多时候我需要的只是"随时掏出来就能问一嘴"的能力。于是我就想，能不能把这套 Harness 直接搬进手机里？

试过一些现成方案，都不太合手。要么是套了个网页壳，交互别扭；要么是重新写一套移动端逻辑，等于推翻重来。后来我看到了腾讯开源的 Kuikly，一个用 Kotlin 做跨端开发的框架，细琢磨了一下方案，最后真把 DeepSeek Harness 装进了口袋。这篇文章就是完整记录，从架构选型到代码实现，再到真机调试踩坑，你照着走一遍也能做出来。

1. 为什么要把 DeepSeek Harness 装进口袋

1.1 Harness 到底解决什么问题

先把这个概念对齐一下，很多人听到 Harness 会以为是某个具体的模型或者新的推理引擎，其实不是。

Harness 在 AI 工程里一般指的是"包裹在模型外面的一整套工作流控制层"。DeepSeek Harness 做的事情，可以简单理解为三块：第一块是模型调用的统一入口，你不需要每次重复写 API 请求、鉴权、错误重试这些低层逻辑；第二块是提示词和上下文的组织，它会根据你的输入自动拼装系统提示词、历史消息、工具调用结果；第三块是工具链的编排，比如搜索、代码执行、结构化输出这些能力，都可以以函数的方式注入到对话流里。

所以真正有价值的不是它帮你省了几行代码，而是它把"和人对话"变成了"和工具对话"，并且让这个过程中的状态管理、流式输出、异常恢复都变成了可复用的标准件。

问题来了，这么一套东西，本质上是跑在 Node.js / Python 这类服务端环境里的。手机上没有 Node 运行时，也不方便直接跑 Python 子进程，那要怎么"装进口袋"？

这就是我这个项目要解决的核心矛盾。

1.2 为什么选 Kuikly 而不是 Flutter / RN

先交代一下选型过程。我最早考虑过 Flutter 和 React Native，毕竟这两个生态成熟，资料也多。但深入一想，有个点绕不过去：DeepSeek Harness 的调用链、数据结构、配置模型，我希望能尽可能地和现有代码共用逻辑，而不是在移动端另起炉灶重写一遍。

Kuikly 的独特之处在于它基于 Kotlin Multiplatform，业务逻辑用 Kotlin 写一遍，Android 和 iOS 都能跑。这对我来说非常关键，因为我的 Harness 侧完全可以用 Kotlin 重新实现核心调度逻辑，然后 UI 层用 Kuikly 的声明式语法直接搭建。

另一个理由是性能。Kuikly 在 UI 渲染上走的是自绘引擎路线，和 Flutter 类似，但因为它和 Kotlin 协程、Flow 这类异步原生的配合更顺畅，所以在做流式输出这种高频更新场景时，代码写起来非常顺手。用 Flow 接收 token 流，再通过 Kuikly 的状态机制驱动界面刷新，整个链路干净利落。

当然 Flutter 也不是不行，但对我来说，Kotlin 一套代码两端复用，加上和现有 Harness 逻辑的亲近感，这个优势太明显了。

2. 整体设计：Harness 移动化的四种路线

2.1 先拆开 Harness 的壳

动手之前，我先把 Harness 内部的结构拆了一遍，搞清楚哪些是"必须保留的核心"，哪些是"可以砍掉的重型依赖"。

一个典型的 DeepSeek Harness 工作流大概长这样：入口接收用户消息 → 加载配置（模型名、温度、top_p 等）→ 组装上下文（系统提示词 + 历史消息 + 工具定义）→ 调用模型 API → 解析流式返回 → 判断是否需要触发工具调用 → 如果有函数调用就执行并把结果回填 → 继续生成下一段内容。

在这个链路里，真正不可替代的是"上下文组装 + 工具调用循环 + 状态管理"这三件事。至于具体的运行环境，其实只是一个执行载体。

2.2 路线对比：远端代理、本地服务和纯重写

我梳理了三条技术路线，逐一做了评估。

第一条是远端代理方案。把 Harness 部署在一台服务器上，对外暴露 HTTP 接口，手机端只做展示层。这个方案实现成本最低，但有两个我忍不了的缺点：一是每次请求都要经过网络中转，延迟明显；二是断网场景下完全不可用，这就违背了"口袋工具"的初衷。

第二条是本地服务方案。在手机里塞一个轻量级运行时（比如通过 Termux 跑 Python），然后 Harness 跑在本地，Kuikly 通过 localhost 调用。这条路理论上可行，但工程复杂度很高。Termux 的 Python 环境在 Android 后台容易被杀，iOS 上又没有类似的运行时，等于只解决了一半问题。

第三条是纯重写方案。用 Kotlin 把 Harness 的核心调度逻辑重新实现一遍，直接跑在 App 进程里。UI 层用 Kuikly 写，所有状态管理、上下文组装、工具调用都在端上完成。代价是工作量最大，但收益也最直接：没有网络中转、离线可用、启动快、交互完全原生。

我最后选了第三条路线，加上一条变通——配置层面保留对远端 Harness 接口的兼容。

2.3 我最终选定的架构

最终的架构可以分成三层。

最底层是 Harness Core，也就是用 Kotlin 重新实现的调度内核。这里包含模型客户端（负责和 DeepSeek API 通信）、上下文管理器（维护会话历史、token 预算控制）、工具注册表（维护可调用的函数列表及其执行逻辑）。

中间层是 Kuikly 的业务逻辑层，负责把 Harness Core 暴露出来的状态转换成 UI 可以消费的数据。比如用一个 Flow 来收集流式输出的 token，然后通过状态持有对象驱动界面变化。

最上层就是 Kuikly 的 UI 层，完全用声明式写法。左边是会话列表，右边是对话窗口，底部是输入框。整个界面看起来和常见的聊天软件差不多，但背后跑的是完整的 Harness 调度逻辑。

这里有个关键决策：不引入任何服务端组件，API Key 直接存在端上加密存储里，所有请求由 App 直连模型接口。这样既保证了架构简单，也把隐私风险控制在一个端上。

3. Kuikly 工程搭建与核心链路实现

3.1 环境准备与第一个 Kuikly 页面

先搭环境。Kuikly 的工程结构和标准 Kotlin Multiplatform 项目类似，你需要准备 JDK 17、Android SDK、Xcode（如果你要编译 iOS 的话），然后在项目里引入 Kuikly 的 Gradle 插件。

我建了一个新工程，模块结构大概是这样的：

com.example.harness ├── core # Harness Core 逻辑 │ ├── model # 请求/响应数据模型 │ ├── client # 模型 API 客户端 │ ├── context # 上下文管理器 │ └── tools # 工具注册与执行 ├── ui # Kuikly 声明式 UI │ ├── chat # 对话页 │ ├── session # 会话列表页 │ └── settings # 设置页 └── platform # expect/actual 平台适配

第一个页面不用复杂，先用 Kuikly 写一个简单的文本展示，验证整条编译链路通不通。在 Kuikly 里，页面是一个 Composable 函数，我用Text组件渲染了一行字，然后分别跑 Android 和 iOS 的构建任务。

这一步看起来简单，但特别重要。Kuikly 的编译链涉及 Kotlin/Native，第一次跑 iOS 构建会下载一堆依赖，耗时比较长。建议先跑 Android 构建确认基础环境没问题，再跑 iOS，排查起来更容易。

3.2 把 Harness 的调用链路搬到 Kotlin

接下来是核心工程。我在 Kotlin 里实现了自己的HarnessClient，先定义好数据模型：

@Serializable data class ChatMessage( val role: String, val content: String ) @Serializable data class ChatRequest( val model: String, val messages: List<ChatMessage>, val temperature: Double = 0.7, val topP: Double = 0.9, val maxTokens: Int = 2048, val stream: Boolean = true ) @Serializable data class ToolCall( val name: String, val arguments: String )

调用部分用 Ktor Client，它天然支持 Kotlin 多平台，Android 底层走 OkHttp，iOS 底层走 Darwin 引擎，一套代码两边跑。

class HarnessClient(private val apiKey: String) { private val client = HttpClient { install(ContentNegotiation) { json(Json { ignoreUnknownKeys = true }) } } fun streamChat(request: ChatRequest): Flow<String> = flow { val response = client.post("https://api.deepseek.com/v1/chat/completions") { contentType(ContentType.Application.Json) header("Authorization", "Bearer $apiKey") setBody(request) }.bodyAsText() // 解析 SSE 流 val lines = response.lineSequence() for (line in lines) { if (line.startsWith("data:")) { val data = line.removePrefix("data:").trim() if (data != "[DONE]") { val json = Json.parseToJsonElement(data) val text = json.jsonObject["choices"] ?.jsonArray?.firstOrNull() ?.jsonObject?.get("delta") ?.jsonObject?.get("content")?.jsonPrimitive?.contentOrNull if (text != null) emit(text) } } } } }

这段代码的关键点是使用了Flow来逐段发出 token。因为对话生成要求流式展示，用户输入之后应该一个一个字地看到回复出现在屏幕上，而不是等全部生成完了再一次性刷出来。用Flow的好处就是天然支持这样的异步序列。

API 地址和鉴权方式我直接写成了可配置项，这样后续如果 Harness 版本升级或者你换了别的模型端点，只需要改配置，不需要动代码。

3.3 上下文管理器与工具调用循环

流式请求只解决了"单次问答"的问题，但 Harness 的灵魂在于它会自动维护上下文，并且能在对话过程中调用工具。

我实现了一个ContextManager，负责每轮对话结束后把新的消息追加到历史列表里，同时做一个简单的 token 预算控制：

class ContextManager(private val maxContextTokens: Int = 8192) { private val history = mutableListOf<ChatMessage>() fun addUserMessage(content: String) { history.add(ChatMessage("user", content)) trimIfNeeded() } fun addAssistantMessage(content: String) { history.add(ChatMessage("assistant", content)) trimIfNeeded() } fun buildMessages(systemPrompt: String): List<ChatMessage> { return listOf(ChatMessage("system", systemPrompt)) + history } private fun trimIfNeeded() { var totalTokens = history.sumOf { estimateTokens(it.content) } while (totalTokens > maxContextTokens && history.isNotEmpty()) { totalTokens -= estimateTokens(history.removeAt(0).content) } } private fun estimateTokens(text: String): Int { return text.length / 2 // 中文场景粗略估算 } }

这里 token 估算用的是"字符数除以 2"这个近似公式。中文场景下，大概两个字符对应一个 token，做一个粗略的预算控制足够用，不需要为了这个引入额外的分词库。

工具调用循环是另一件大事。我实现了一个工具注册表，每个工具就是一个函数，定义好名称、描述和参数格式后，在模型返回tool_calls的时候自动触发执行，然后把结果回传。

fun interface HarnessTool { suspend fun execute(arguments: String): String } val tools = mutableMapOf<String, HarnessTool>() fun registerTool(name: String, tool: HarnessTool) { tools[name] = tool }

真实场景中，我自己注册了两个工具：一个是get_current_time，用来做时间相关问答；一个是search_notes，用来在本地笔记库里做关键词检索。这两件事都不需要联网，跑在端上就能执行，响应速度非常快，也给用户一种"这个助手是真的会干活"的感觉。

3.4 UI 层设计：让手机上的交互不别扭

底层链路打通之后，UI 层就是重头戏了。Kuikly 的 UI 写法和 Compose 非常像，声明式、状态驱动。我设计了一个简单的双页面结构：主页面是聊天窗口，侧面抽屉是会话列表。

聊天窗口的关键点在于列表的自动滚动和流式刷新。我定义了一个ChatState：

class ChatState { var messages by mutableStateOf(listOf<UiMessage>()) var isGenerating by mutableStateOf(false) }

在收到流式 token 时，不是每次emit都去更新整个列表，那样性能会很差。我的做法是在工具侧做一个缓冲：维护一个StringBuilder，每次收到 token 先追加进去，然后隔 30 到 50 毫秒刷一次 UI。这样既保证了视觉上的流畅，又避免了每一帧都触发重组。

页面代码的骨架大概是这样的：

@Composable fun ChatScreen(state: ChatState, onSendMessage: (String) -> Unit) { Column { MessageList(messages = state.messages) InputBar(onSendMessage = onSendMessage) } }

UI 这块我多花了一些心思在输入框的交互上。手机上打字不方便，所以我在输入框上方加了一排快捷指令按钮，比如"总结当前话题""翻译上一条回复""列出关键点"。这些快捷指令其实就是在发送前把预设的提示词模板插进去，本质上还是在调用 Harness 的提示词管理能力，但用户体验提升了一大截。

4. 真机调试与打包：那些不跑一遍根本发现不了的坑

4.1 编译链路的坑

Kuikly 的跨端编译机制和 Flutter 不太一样，它是基于 Kotlin Multiplatform 的，所以 Android 走的是 JVM 编译，iOS 走的是 Kotlin/Native 编译。这就导致一个问题：很多在 Android 上正常的代码，在 iOS 上可能编译不过去，尤其是涉及反射、序列化这类涉及运行时特性的东西。

我实际遇到的一个具体问题是 kotlinx.serialization 在 iOS 上的 JSON 解析策略和 Android 有细微差别。同样是解析null字段，Android 端会忽略并保留默认值，iOS 端在某些配置下会直接抛异常。最后我的解决方法是给所有数据模型都加上默认值，并且在整个工程里统一开启ignoreUnknownKeys = true。

这类问题排查起来很费时间，因为两个平台的日志风格不一样。Android 上直接看 Logcat 就行，iOS 上得用 Xcode 的设备控制台。建议在开发初期就养成一个习惯：任何数据类都显式声明默认值，任何 JSON 字段都允许未知字段，这个小习惯能帮你省掉无数个抓狂的夜晚。

4.2 网络与数据格式的坑

真机调试遇到的第二个大头是网络。Android 模拟器默认可以通过10.0.2.2访问宿主机，但真机没有这个概念。如果你像我一样在本地跑了一个 Harness 服务用于联调，注意不要把localhost写死在代码里。我的做法是在设置页增加了一个可配置的 API 地址，默认指向线上模型接口，但允许在调试时改成局域网内服务器的 IP。

另外一个坑是 API Key 的安全。我一开始图省事，把 Key 直接写在了代码里，结果被同事提醒这样太危险。后来改成了端上加密存储：Android 用 EncryptedSharedPreferences，iOS 用 Keychain，通过 expect/actual 封装成一个统一的接口。这个改动不复杂，但属于"不做会出事"的级别。

还有流式返回的解析，我发现 DeepSeek 的 SSE 格式在某些情况下会返回多条data在同一行，如果只是简单按行解析会漏数据。我的解决方法是先把整个响应按data:切分，然后再逐段解析，这样兼容性更好。

4.3 端上性能优化实测

第一个性能瓶颈是列表刷新。最开始我在每个 token 到达时都触发一次messages的更新，结果列表在长对话时卡顿非常明显。后来优化成"批量刷新 + 最后一条消息原地修改"，滑动流畅度立刻上了一个台阶。

第二个瓶颈是记忆体占用。长对话的 token 数会持续增长，如果不加控制，几百轮之后上下文早就爆炸了。我做的处理是分两级：第一级用 ContextManager 做 token 预算裁剪，超出部分从最早的对话开始丢弃；第二级在 UI 层只保留最近 50 条消息的完整内容，更早的折叠成摘要。这样既保证了对话质量，也控制了内存。

真机实测下来，一个包含 100 轮对话的会话，内存占用大概在 80 到 120 MB 之间，滑动帧率基本维持在 58 到 60 帧。这个数据在可接受范围内，日常使用完全感觉不到卡顿。

5. 常见问题速查与实操心得

5.1 问题与排查一览

5.2 几点实操心得

这套方案做下来，我最深的体会有三条。

第一条是跨端框架的价值不在 UI 而在逻辑复用。Kuikly 对我来说最大的意义不是省掉了写两套界面的工作量，而是让 Harness Core 这一整层模型调度逻辑可以用 Kotlin 写一遍、两端共享。UI 重写是不可避的，但核心业务逻辑的复用让整个项目的维护成本低了一大截。

第二条是移动端的大模型应用，核心体验在于交互节奏。流式输出、列表滚动、键盘弹出这些细节，每一样都会直接影响用户对"这个工具跟不跟手"的判断。我在性能优化上花的时间比写业务逻辑多得多，但回头看是值得的。

第三条是别过度设计。我最初想过在端上引入数据库、做复杂的权限系统、甚至打算给工具调用加一个可视化编排界面，后来被现实教育了。首个版本能做扎实"对话 + 上下文 + 几个实用工具"这三件事，比堆一堆花哨功能重要得多。

如果你也想把自己常用的 AI 工具链搬到手机上，我的建议很简单：先去把你现有的 Harness 拆成"核心逻辑"和"执行环境"两部分，然后找一个能复用你主力语言的跨端框架，一次只做一件事，先把最小闭环跑通。项目在路上慢慢迭代，工具顺手不顺手，只有每天摸手机的时候才知道值不值。