大语言模型在demo阶段总是看起来很惊艳。但一旦进入到生产环境很多问题就暴露了：不稳定、不可预测，甚至直接不可用。

从实践来看核心问题很少出在模型本身。更多时候是在于如何设计、评估和迭代应用模型的提示词。LLM应用的输入提示词必须适配具体任务，才能让模型在期望的输出范围内工作。

提示词工程在今天基本还是被当作一种"艺术"。这篇文章要讨论的就是为什么这是个问题，以及怎么把它变成一门可度量的工程学科。

提示词工程仍然是猜测

大多数团队的提示词改进流程其实很粗糙：有人写（或重写）提示词，跑几个例子，主观觉得"感觉好了一些"，然后就上线了。

没有度量标准，没有基线，也没有对"更好"的明确定义。

这带来的直接后果是：提示词质量难以对比，评估基本靠外部响应来判断，回归问题不容易察觉，很多故障等到上线后才被发现。

提示词工程本质上极度主观，如果目标是构建可靠的AI系统，这就成了一个严重的瓶颈。

实际LLM使用中的两个对立问题

在生产环境里跑LLM，我发现有两个反复出现的问题。

不一致性：同一个提示词，不同的答案

同一条提示词跑多次会产生明显不同的输出。这不只是烦人的问题，而是对数据流水线、自动化决策系统、评估框架来说，这是实打实的可靠性风险。

高方差在这类场景下是bug不是feature。模型要么表现出确定性行为，要么至少得在可控范围内运行。

缺乏多样性：模型不够有创造力

反过来，有好几个实际项目中碰到了相反的困境：做创意生成、探索性分析、创意制作这类任务时，模型产出的内容彼此过于相似，概念覆盖面非常窄。一旦规模化，创造力就丢得干干净净。

这时候确定性就从优势变成了束缚。

一个简单的假设

提示词质量应该是可衡量的。

有些任务需要最小化输出方差，有些任务需要最大化多样性，而提示词的变更应该能推动结果朝可度量的方向移动。不同类型的任务也可以选择不同的度量标准。

既然模型行为可以衡量，提示词行为为什么不能？

为了验证这个想法，我选了模型行为的一个切面来入手：响应多样性，把它当作创造力的代理指标。

目标不是找到完美的度量方式，而是回答两个问题：提示词变更能不能转化为一致的数值差异？单次任务上的创造力/确定性到底取决于提示词还是仅取决于温度？

实验设置

实验规模不大，设计如下：

提示词

提示词A：

"Create 5 ideas of creative banners for performance marketing of an AI benchmarking platform."

提示词B在A的基础上加了一条指令：

"Create 5 ideas of creative banners for performance marketing of an AI benchmarking platform. Be as creative as possible."

模型和采样

采用单次生成模式，测试了多个LLM（具体型号这里略过），温度分别设为0 × max、0.5 × max和1 × max。每个（提示词、模型、温度）组合跑10次。

测试集选了4个主流模型家族的13个模型：OpenAI的GPT系列、Google的Gemini系列、Antropic的Claude系列，以及Deepseek。

通过Embedding衡量多样性

每条生成结果都计算了4096维的embedding向量。然后对每个实验集（固定提示词、模型和温度），取集合内embedding的最大成对距离作为响应多样性的度量。

逻辑很简单：距离小说明行为高度确定，距离大说明输出多样且有创造力。最终得到一个数值，描述模型响应的"分散程度"。

结果

汇总表，创意提示词版本导致了更显著的分散。同时温度并不总起作用。

基础提示词和创意提示词在模型-温度切片上的比较图。

每个模型在不同温度水平上的响应分散图

结果比预期要清晰得多。

跨模型来看有三个明显趋势：在提示词中加入明确的创造力指令，曲线一致上移；提高温度在一定程度上增大了响应多样性，但受限于小样本，这个结论还需谨慎看待；各模型对温度变化的响应方式差异很大没有统一规律。

提示词变更带来的是可预测的数值效果，而非随机噪声。

这说明两件事：提示词迭代不必完全依赖直觉，输出创造力是可量化的；这一假设有可能推广到更大的样本和不同的应用场景。

这套方法的实际意义在于：提示词可以通过数值做A/B测试，温度调优有了度量依据而不是靠猜，模型选择可以由任务需求驱动而非跟风。

它让团队能在提示词变更上线之前就对效果做出推断。

局限性

结果虽然是正向的但有几个局限

度量标准的任务特定性

这里定义的"创造力"严格来说是任务相关的。用embedding距离衡量的响应多样性，在创意生成、营销创意、探索性任务上作为创造力的代理指标还算合理，但在事实性问答、代码生成、结构化数据提取这些场景下可能毫无意义，甚至会产生误导。

不能把它当成模型质量的通用指标。目前我也在测试其他面向不同任务的度量标准。

对Embedding空间的依赖

所有测量都建立在特定embedding模型和距离度量之上。换用不同的embedding模型、向量归一化方式或距离函数，绝对值也是会变的，所以模型间的相对排名也可能有所不同。

但本实验中观察到的趋势是稳定的，所以结果应当按相对值来解读，不宜绝对化。

有限的样本量

每个配置只跑了有限次数。趋势虽然一致，但要减少方差、估计置信区间、得出统计上站得住的结论，样本量还远远不够。当前的发现更多是探索性的，不是定论。

提示词和领域偏差

实验只用了一种任务表述和一个窄领域（效果营销创意）。换到其他领域或提示词风格，效果可能更弱、更强，也可能呈现完全不同的行为模式。把这些结论向创意任务之外推广需要格外谨慎。

创造力与实用性的权衡

响应多样性高不等于结果好。高度多样化的输出里可能混着不相关的想法、低质量的建议和不连贯的回复。这个实验测的是方差，不是实用性更不是商业价值。实际应用中创造力度量必须和质量过滤或下游评估配合使用。

LLM的非平稳性

大语言模型会被提供商持续更新，所以绝对分数可能随时间漂移，分数可能在提示词没改的情况下发生变化，可复现性也可能下降。任何长期的基准测试工作都必须把这种非平稳性纳入考量。

相关性不意味着因果性

最后要说的是，温度、提示词指令和响应多样性之间虽然有明确的相关性，但这不代表对模型行为有了完整的因果理解。实验证明的是"提示词变更可以被衡量"，而不是创造力可以被这套度量标准完全解释。

总结

这只是一系列研究的第一个实验，后续结果会在接下来的文章中陆续呈现。下一步计划：增加样本量，尝试不同的提示词，实验如何降低创造力，为其他类型任务定义新的度量标准，以及构建一个定期更新的模型排行榜来覆盖各项指标。

https://avoid.overfit.cn/post/e84eee36d7bc4263b9fd5dfe564e21d9

作者：Alexey Konoshenkov

前段时间我写过一篇文章，记录自己作为一名 PHP 开发者自学 Go 的过程

那篇更多是学习阶段的整理。这次则是一次完整实践的复盘。

单点知识和系统能力之间始终存在差距。

理解一个概念并不难，但要把多个能力组合起来，形成一个可以长期运行的系统，往往需要真实项目去反复打磨。很多看似基础的东西，只有亲手做过，理解才会真正扎实。

最近我完成了一个小工具：github-webhook-listener

一个用 Go 实现的 GitHub Webhook 接收服务，可以根据规则执行 Shell 命令，并内置一个简单的 Vue 面板，用于查看运行状态和执行记录。

功能本身并不复杂，AI 也完全可以在较短时间内生成类似的实现。但在实际开发过程中，我更在意的并不是功能本身，而是一些基础层面的设计问题：项目结构如何划分，依赖如何组织，边界如何定义，以及构建与部署如何简化。

这些内容未必新鲜，但当它们被组合到一个完整系统中时，体会是不同的。

项目地址我放在文章末尾，感兴趣可以自行查看下载使用。

下面我会从结构设计、并发模型以及构建方式三个方面，做一次相对完整的技术复盘。

项目结构与职责划分

项目核心代码放在 internal 目录：

internal/
├── bootstrap
├── handler
├── service
├── repository
├── model
├── dto

这种结构并不追求“标准答案”，重点在于依赖方向清晰。

repository

• 只负责数据库操作
• 不包含业务判断
• 不依赖 HTTP

service

• 负责业务逻辑
• 调用 repository
• 不处理 HTTP 细节

handler

• 只做参数解析与响应封装
• 调用 service
• 不包含核心逻辑

在功能简单时，这种分层似乎有些“多余”。

但当涉及到任务调度、执行记录、重试机制时，结构边界开始体现价值。

边界明确之后，功能扩展基本是“局部修改”，而不是结构性调整。

在 bootstrap 中组织依赖关系

所有初始化逻辑集中在 bootstrap 包中完成：

1. 初始化数据库
2. 创建 repository
3. 注入到 service
4. 注入到 handler
5. 注册路由

依赖关系在入口处完全展开，而不是在各个文件中隐式创建。

这种方式带来的最大好处是：

• 对象生命周期清晰
• 依赖方向可控
• 替换实现时改动集中

在没有使用任何 DI 框架的情况下，通过显式构造函数完成依赖注入，本身就是对依赖关系的一种约束。

当项目规模不大时，这种方式反而比自动注入更透明。

双队列 Worker Pool 的并发调度模型

这个项目的核心之一，是执行 Shell 命令并控制并发数量。

我实现的是一个“双队列 Worker Pool”结构，主要包含三个核心组件：

1. 任务生产者（Producer）
2. 集中式调度器 + Worker Goroutine
3. 结果处理器（Result Processor）

第一层：任务生产者

当 Webhook 触发或 Web 面板手动触发任务时，任务被封装为一个结构体，发送到调度队列。

这一层只负责“生成任务”，不关心执行细节。

第二层：集中式调度器 + Worker Pool

调度器内部维护：

• 一个任务输入队列
• 一个固定数量的 worker goroutine

调度流程：

• 调度器从任务队列中取出任务
• 分发给空闲 worker
• worker 执行 Shell 命令
• 将执行结果发送到结果队列

worker 数量可控，因此系统并发是有上限的。

这种结构的优点：

• 并发可控
• 不会因为 Webhook 高频触发而无限创建 goroutine
• 任务调度逻辑集中管理

相比“每来一个请求直接开 goroutine 执行”的写法，这种结构在可控性和可扩展性上更好。

第三层：结果处理器

worker 不直接写数据库，而是把结果推送到结果队列。

结果处理器负责：

• 更新执行记录
• 写入数据库
• 处理重试逻辑（如果有）

这样做的目的，是进一步解耦：

• 执行逻辑专注执行
• 持久化逻辑专注记录

这就是“双队列”的意义：

• 队列一：任务调度
• 队列二：结果处理

这种分离在系统规模变大时尤为重要，因为执行耗时和持久化耗时是两个不同维度的问题。

Makefile 作为构建入口

项目使用 Makefile 统一管理：

• 后端构建
• 前端构建
• 交叉编译
• 发布打包

Makefile 在这里的意义并不是“少打几行命令”，而是：

• 所有构建流程被显式记录
• 新环境下可直接复现
• 发布步骤标准化

当一个项目开始涉及前后端协作、交叉编译和发布时，构建流程本身就成为项目的一部分。

使用 embed 将前端资源打包进二进制

这是我在这个项目中感受最明显的“Go 工程优势”。

前端使用 Vue 构建完成后，静态资源通过 embed 打包进 Go 二进制中。

然后通过：

http.FileServer(http.FS(...))

直接提供访问。

最终效果是：

• 只有一个可执行文件
• 不需要 Node 环境
• 不需要单独部署前端
• 不依赖外部静态文件目录

从架构上看，它仍然是前后端分离：

• 前端独立开发
• 后端提供 API

但从交付形态看，它又像是传统单体应用：

• 单文件分发
• 直接运行

这种组合非常适合工具型项目和内部服务。

Go 在这一点上确实有明显优势：编译后就是完整产物，不需要运行时环境，不依赖包管理器，不依赖额外解释器。

分发成本几乎为零。

写在最后

这个项目没有刻意追求复杂设计，也没有引入额外框架。

它更像是一次完整的工程实践：把分层、依赖组织、并发控制、构建管理这些已经学过的能力组合在一起，形成一个可长期运行的系统。

我自己已经在实际环境中持续使用它，用来自动化部署和执行脚本，稳定性和可维护性都符合预期。对我来说，它已经从“练手项目”变成了日常工具。

如果你刚好也需要一个简单的 GitHub Webhook 执行工具，可以直接拿去用；

如果你正在学习 Go，想找一个结构完整、但复杂度可控的小项目作为参考，也可以看看实现细节。

GitHub 仓库地址：点击查看

有问题或者想法，也欢迎直接在 GitHub 上交流。

🍁 枫琳 (Fenglin)

人机共生智能协作平台 - 让智能自然融入生活

一、产品简介

枫琳 是一款实现人与智能体（OpenClaw、OpenCode 等）和谐相处、共同交流、生活、工作的智能协作平台。支持接入钉钉、企业微信等办公软件，覆盖朋友圈、点赞、评论、私信等社区场景，实现人与机器人共生，共同进步，就像人与自然和谐共生一样。

品牌理念

"枫叶由绿转红，是成长的印记；人机由陌生到默契，是共生的旅程"

二、核心功能

1. 🤖 智能体协作

枫叶随风起舞，人与 AI 自然共处

• 多智能体协同工作 - 支持 OpenClaw、OpenCode 等多种智能体
• 智能任务分配 - AI 自动分析并分配最优任务
• 实时沟通反馈 - 人机无缝对话，即时响应

2. 🏢 企业级集成

枫枝相连，生态融合

• 钉钉深度集成 - 无缝对接企业钉钉工作流
• 企业微信对接 - 支持企业微信生态
• 自定义工作流 - 灵活配置企业专属流程

3. 💬 社区生态

枫叶飘落，信息传递；琳玉相击，思想共鸣

• 朋友圈动态分享 - 发布图文、视频动态
• 实时互动评论 - 点赞、评论、转发
• 安全私密对话 - 端到端加密私信

4. ✨ 智慧共生

枫叶四季蜕变，持续成长

• 知识共享沉淀 - 构建团队知识库
• 能力互补提升 - 人机优势互补
• 共同成长轨迹 - 记录每一步进步

三、应用场景

四、产品优势

五、品牌色彩体系

六、品牌 Slogan

主 Slogan：

枫琳，让智能自然融入生活

场景 Slogan：

七、开源项目

本产品为开源项目，欢迎参与贡献：

🔗 Gitee 仓库： https://gitee.com/hongmaple/openclaw-dindin-chart

八、快速开始

1. 注册账号

访问枫琳官网，点击"免费试用"按钮

2. 创建工作空间

选择你的行业场景，系统将为你推荐合适的智能体

3. 开始协作

与智能体开始对话，让它成为你的得力助手

九、联系我们

十、相关链接

🍁 枫琳 - 人机共生，自然之道

让 AI 如枫叶般自然融入你的工作与生活

本文由mdnice多平台发布

从开服第一天起，就跑在云上；

上线一年，DAU 已经突破 1000 万；

高峰期百万玩家同时在线，零重大故障。

这不是科幻，而是巨人网络与阿里云共书写的云原生实战。

《超自然行动组》的云原生架构先行战略

2025 年 1 月，巨人网络推出多人组队欢乐冒险游戏《超自然行动组》，凭借创新的“中式微恐+多人合作"的独特玩法，迅速成为现象级产品。最近，《超自然行动组》宣布 DAU 突破 1000 万，更攀升至 iOS 游戏畅销榜第四。尤为值得一提的是，自开服第一天起，这款游戏从未部署在任何物理机或传统虚拟机上——它从第一天起，就运行在云原生架构之上 。

对于大多数游戏公司而言，“上线即爆款” 是甜蜜的烦恼——流量洪峰来得快、退得慢，而传统架构却“笨重”：

• 游戏服（如战斗服、房间服）部署在固定服务器，扩容需数天；
• 为应对峰值需长期预留资源，空闲时浪费严重；
• 版本更新靠脚本，灰度发布难，一出错就“全服回滚”；
• 日志分散、监控割裂，故障定位动辄几小时；
• 安全防护薄弱，易受 DDoS 攻击；
• 数据层瓶颈突出：战斗结算延迟、排行榜卡顿、玩家数据丢失等问题频发。

《超自然行动组》团队深知：若沿用旧模式，很可能“倒在成功的路上”。

于是，他们选择了一条更难但更远的路——全面拥抱云原生。

通过 ACK（容器服务）、ESS（弹性伸缩）、网络型负载均衡 NLB、OpenKruiseGame（OKG）、SLS（日志服务）、ARMS（应用实时监控服务）、阿里云原生防护（Native Protection），以及云原生数据库 polardb 和 Redis 的深度协同，巨人网络构建了一套高弹性、高可用、低成本、智能化、高安全且高性能数据处理能力的新一代游戏基础设施，为行业树立了云原生落地的标杆。如今，随着日活跃用户（DAU）突破千万大关，这套技术体系，已经成为游戏行业“云原生转型”的标杆案例。

高弹性×低延迟×零故障：解码<超自然行动组>的云原生底座

《超自然行动组》基于阿里云 ACK 与 OpenKruiseGame（OKG）构建了业界领先的云原生游戏服架构：通过蓝绿发布与原地升级实现零停机、无感交付；通过 OKG+多 NLB 资源池，全面覆盖 BGP、电信、联通、移动等主流线路，实现多运营商网络自动化映射。结合 HPA 智能扩缩容与 OKG 优雅下线机制，在成本与用户体验间取得平衡；通过 ACK Koordinator 组件，实现 CPU Burst 与 QoS 精细化调度，显著提升集群资源利用率；并通过基础设施与业务状态的双向感知，构建起“业务语义驱动”的自动化运维闭环——真正实现了高弹性、高可用、高性能、高安全的新一代游戏后端体系。在显著降低运维压力的同时，实现了机制化、可持续的成本优化。

在网络层面，作为一款对延迟极度敏感的竞技手游，《超自然行动组》依托阿里云打造了“云边协同、三网通吃、弹性集约”的新一代云网络架构：通过 OKG 与 NLB 实现电信、联通、移动、BGP 四线并发接入，全国玩家自动匹配最优链路，并以“静态网络+动态计算”创新模式达成 50 节点/分钟的极速扩容，15 分钟内可拉起数千战斗服，彻底告别排队；同时，借助阿里云高速通道，将本地机房的账号、支付等核心系统与上海 VPC 内网直连，构建毫秒级同步、金融级安全的混合云中枢；并通过共享带宽包统一聚合公网出口，在简化运维的同时显著降本，为玩家交互与高频状态同步提供弹性“带宽蓄水池”，真正实现千万玩家同场竞技零卡顿、零等待的极致体验。

在数据层面，云原生 polardb 和 Tair（兼容 Redis）构建了弹性，稳定的玩家存档方案，支持千万级玩家高并发登录和读写，基于 polardb 云原生数据库的存算分离和弹性能力，支持游戏在活动期间自动扩展弹性，并且支持玩家数据的秒级备份和回档，大幅降低了数据库的运维成本，并且 PolarDB Serverless 支持自动扩容和缩容，能够根据用户访问量的实时变化，秒级调整计算资源。在高峰时期自动增加资源，低谷时期自动减少资源，确保社区始终运行在最佳状态。基于阿里云 Tair（兼容 Redis）支持玩家超高并发的访问，作为实时排行榜、战斗状态缓存和匹配池的核心，依托多线程与持久内存优化，单实例 QPS 超百万，实现毫秒级排名刷新、瞬时结算与断线无缝恢复。

当数百万玩家涌入《超自然行动组》，DDoS 攻击成为影响体验的关键风险。为此，巨人网络联合阿里云，基于云原生安全架构打造了一套高性能、智能化的防护体系。该方案依托阿里云原生高防能力，无需架构改造，一键接入即可实现 TB 级 DDoS 攻击的毫秒级识别与精准清洗，防护能力行业领先。即便在版本更新或大型赛事等高并发场景下，系统仍保障 99.99% 以上服务可用性，真正做到“攻击零感知、切换无中断”。面对突发流量洪峰，系统支持防御带宽自动弹性伸缩，动态调配资源，避免因容量不足导致服务中断。同时，通过集成安全事件中心，运营团队可实时监控攻击事件，分析攻击类型与特征，并结合 AI 驱动的策略建议，快速部署定制化游戏协议防护规则，显著提升响应效率与防御精准度。从高效清洗到智能决策，阿里云以“稳定、高效、安全”为核心，为《超自然行动组》构筑起坚不可摧的数字护盾，在保障千万玩家流畅竞技的同时，也为游戏行业树立了云原生安全新标杆。

对于《超自然行动组》这款主打实时互动的竞技游戏，“能跑” 只是起点，“看得清、查得准” 才是保障千万玩家流畅体验的关键。运维团队摒弃传统分散监控工具，基于阿里云日志服务 SLS 、云监控 CMS 的 Prometheus 服务、Grafana 服务，搭建起轻量、标准、深度集成的可观测体系：

• 依托 Prometheus 实时采集百万级 PCU 下的资源水位与在线人数、匹配时长等核心业务指标，确保高并发下监控精准不丢点；
• 通过 SLS 统一汇聚全链路日志，支持按 RequestID / 玩家 ID 秒级还原行为路径，结合 SQL 分析与自定义规则，实现地图报错统计、异常操作追踪；
• 借助 Grafana 打造统一全景大盘，融合展示指标与日志数据，告警时可一键跳转 SLS 查看关联日志，实现 “指标发现问题、日志定位根因” 的闭环，将故障响应时间从小时级压缩至分钟级，充分发挥云原生可观测与协同优势。

超自然云原生架构

从“能跑”到“跑赢”：OKG 重塑游戏后端新范式

当一款游戏从“能跑”走向“跑得快、跑得省、跑得稳”，背后一定有一套先进的技术底座在支撑。《超自然行动组》的故事，源于巨人网络，也属于所有正在思考“如何用云原生重构游戏后端”的开发者。

面对全球游戏市场对高并发、低延迟及快速迭代的极致追求，OpenKruiseGame (OKG) 作为阿里云打造的“为游戏而生”的云原生游戏服管理方案，正成为推动行业架构平滑升级的核心引擎。针对游戏业务特有的异构性管理难题，OKG 提供了从精细化配置、自动化网络接入到业务状态感知的一站式管理体系。它不仅极大降低了游戏厂商的云原生转型门槛，更通过全球多地域一致性交付能力，助力开发者突破地域限制，实现业务的快速敏捷部署与全球化扩张。

云原生，已不再是互联网应用的专属，而是下一代游戏基础设施的必然选择。

研究背景

在教育信息化 2.0 行动计划的推动下，数字化学习工具逐渐融入中小学的日常教学与课后辅导中。中小学生的注意力持续时间较短，传统的刷题模式形式单一、趣味性不足，难以调动学生的学习积极性，而游戏化学习模式将学习与互动、竞赛相结合，能够有效提升学生的参与度和学习效率。
微信作为国内用户量最大的社交平台，其小程序生态日趋完善，具有无需下载安装、即用即走、开发成本低、传播便捷等特点，非常适合开发轻量化的教育类应用。同时，腾讯微信云开发技术为小程序提供了一站式的云端开发解决方案，无需开发者搭建独立的服务器和域名，降低了小程序的开发和部署门槛，为教育类小程序的快速开发提供了技术支撑。在此背景下，设计并实现一款基于微信云开发的中小学学科答题小程序，能够满足校方、教师的教学辅助需求和家长的课后辅导需求，助力中小学教育的数字化转型。

主要研究内容

（1）通过调研中小学教学和课后辅导的实际需求，结合游戏化学习理论，完成小程序的功能性和非功能性需求分析，并进行技术、经济、操作可行性分析；
（2）确定小程序的设计原则，设计基于微信云开发的系统架构，将小程序划分为前端用户模块和后台管理模块，并对各模块的功能进行详细设计；
（3）根据需求分析和总体设计，完成小程序的数据库设计，设计用户表、题库表、答题记录表、竞赛表等核心数据表的结构；
（4）选择微信小程序平台和腾讯云开发技术作为核心技术栈，完成小程序前端页面的开发、云函数的编写和后台管理功能的实现；
（5）制定详细的系统部署步骤，完成小程序的本地部署和云端发布，并设计功能测试用例，对小程序的各项功能进行测试，验证系统的稳定性和实用性；
（6）总结本次研究的成果和不足，对小程序的后续优化和功能拓展进行展望。

系统需求分析

需求分析是系统开发的基础，通过调研校方、教师、家长和学生的实际需求，明确系统的功能和性能要求，为后续的系统设计和实现提供依据。本次调研采用问卷调查和访谈相结合的方式，调研对象包括中小学教师、家长和学生，共发放问卷 300 份，回收有效问卷 286 份，访谈中小学教师 20 名、家长 30 名。

功能性需求

根据调研结果，将中小学学科答题小程序的用户分为普通用户（学生）、管理用户（教师 / 家长 / 校方管理员） 两类，不同用户的功能性需求不同，同时小程序需满足基础的系统管理需求，具体功能性需求如下：
2.1.1 普通用户（学生）需求
普通用户为中小学学生，核心需求是通过小程序进行学科知识点的练习和答题竞赛，具体需求包括：
（1）用户登录：支持通过微信授权快速登录，无需单独注册账号，登录后可查看个人信息和答题记录；
（2）题库选择：支持按照学科（数学、语文、英语等）和知识点对题库进行分类筛选，方便学生选择针对性的知识点进行练习；
（3）随机抽题：支持选择特定学科或知识点，由系统随机生成题目进行练习，抽题数量可灵活选择；
（4）答题练习：答题过程中显示题目序号、题干和答题选项，支持选择题、判断题等常见题型，答题完成后即时显示答题结果；
（5）解析详解：每道题目答题完成后，提供详细的解答和解题思路解析，帮助学生理解错题原因，巩固知识点；
（6）答题竞赛：支持参与模拟竞赛，竞赛前可查看竞赛规则（答题时间、题目数量），竞赛过程中倒计时显示，答题完成后即时显示竞赛成绩；
（7）排行榜查看：支持查看答题竞赛的积分排行榜，按积分从高到低排序，显示用户昵称、积分和排名，提升学习的竞争性；
（8）个人中心：支持查看个人答题记录（答题次数、正确率、错题集）、竞赛记录（竞赛次数、最高成绩、平均成绩），可修改个人昵称等基础信息。

系统基础需求

（1）权限管理：实现超级管理员和普通管理员的权限分离，超级管理员拥有所有操作权限，普通管理员仅拥有题库管理、答题参数设置等部分权限；
（2）数据备份与恢复：支持对题库、用户信息等核心数据进行备份，防止数据丢失；支持在数据异常时进行数据恢复；
（3）缓存清理：支持清理小程序的本地缓存，提升小程序的运行速度。

性能需求

（1）响应速度：小程序前端页面的加载时间不超过 3 秒，随机抽题、答题结果展示、排行榜查看等操作的响应时间不超过 1 秒；
（2）并发处理：支持至少 100 名用户同时参与答题竞赛，系统无卡顿、无延迟；
（3）数据处理：支持 Excel 文件批量导入题库，5000 条数据的导入时间不超过 30 秒。

技术可行性

本小程序基于微信小程序平台和腾讯微信云开发技术进行开发，相关技术均为腾讯官方推出，技术文档完善、社区支持活跃，开发门槛较低。
（1）微信小程序的开发框架提供了丰富的组件和 API，支持前端页面的快速开发，且兼容 iOS 和 Android 两大移动操作系统；
（2）微信云开发技术提供了云函数、云数据库、云存储、定时器等一站式云端服务，无需开发者搭建独立的服务器和域名，降低了后端开发的复杂度；
（3）开发所需的辅助技术如 Node.js、NPM 均为开源技术，学习资源丰富，开发者可快速掌握；
（4）微信开发者工具为小程序的开发、调试、预览、部署提供了一体化的支持，支持本地调试和真机测试，方便开发过程中的问题排查。

经济可行性

本项目的开发和部署成本较低，后期维护成本几乎为零，具有良好的经济可行性：
（1）开发成本：项目基于开源技术和腾讯免费的云开发基础配额进行开发，开发过程中无需支付软件授权费、服务器租赁费、域名注册费等费用；
（2）部署成本：微信云开发的资源配额价格低廉，基础版配额可满足中小学校方的日常使用需求，即使后续需要提升资源配额，费用也远低于传统的服务器部署；
（3）维护成本：微信云开发由腾讯官方进行维护，无需开发者进行服务器的运维、升级、安全防护等工作，节省了大量的维护人力和物力成本；
（4）使用成本：小程序对用户完全免费，用户无需支付任何费用即可使用所有功能，易于推广和使用。

系统总体设计

模块化设计原则：将系统划分为多个独立的功能模块，每个模块实现特定的功能，模块之间通过统一的接口进行交互，降低模块之间的耦合度，方便后续的功能扩展和 bug 修复；
用户体验优先原则：结合中小学生和管理员的使用习惯，进行前端界面和操作流程的设计，保证界面友好、操作简单，提升用户的使用体验；
轻量化设计原则：基于微信小程序 “即用即走” 的特性，简化前端页面的代码和资源，降低小程序的代码包大小，提升页面的加载速度；
云原生设计原则：充分利用微信云开发的技术优势，将业务逻辑、数据存储、文件存储均部署在云端，实现前后端的解耦，降低本地开发的复杂度；
权限最小化原则：针对不同的管理员角色分配最小的操作权限，超级管理员拥有所有权限，普通管理员仅拥有必要的操作权限，保证系统的数据安全；
可扩展设计原则：在系统架构和数据库设计中，预留扩展接口和字段，方便后续新增功能和扩展数据类型，适应不同用户的个性化需求。

数据库设计

本小程序采用微信云开发的云数据库进行数据存储，云数据库是一种非关系型数据库（NoSQL），以集合（Collection）为单位存储数据，每个集合包含多个文档（Document），文档采用 JSON 格式存储数据，具有灵活的结构，适合小程序的轻量化开发需求。根据系统的功能需求，设计用户集合、题库集合、答题记录集合、竞赛记录集合、管理员集合、答题参数集合、系统日志集合七个核心集合

前端功能实现

小程序前端是用户与系统的交互界面，采用 WXML、WXSS、JavaScript 进行开发，遵循微信小程序的页面 - 逻辑 - 配置开发模式，每个页面由.wxml（页面结构）、.wxss（页面样式）、.js（页面逻辑）、.json（页面配置）四个文件组成。前端功能实现的核心是通过微信云开发的 API 与云端进行交互，将用户的操作请求发送至云函数，接收云函数返回的处理结果，并完成页面的动态渲染。

云函数实现

云函数是本小程序的业务逻辑处理核心，基于 Node.js 开发，核心云函数为mcloud，包含用户管理、题库管理、答题处理、竞赛管理、参数设置、数据统计六大业务模块的处理逻辑。云函数的开发遵循模块化原则，将不同的业务逻辑拆分为不同的函数，通过action参数区分前端的请求类型，实现对不同请求的处理。

// 得分统计
    async statAnswer(userId) { 
        let where = {
            ANSWER_USER_ID: userId,
            ANSWER_TYPE: 1
        }
        let cnt = await AnswerModel.count(where);
        let score = await AnswerModel.sum(where, 'ANSWER_SCORE');

        let data = {
            USER_ANSWER_CNT: cnt,
            USER_ANSWER_SCORE: score
        }
        await UserModel.edit({ USER_MINI_OPENID: userId }, data);
    }

    // 每日可答题次数校验
    async isAnswerTimes(userId, cateId) {
        let dayCnt = 100;
        let setup = await setupUtil.get('answer');
        if (setup) {
            setup = dataUtil.dbForms2Obj(setup);
            dayCnt = Number(setup.daycnt);

            if (setup.open != true) {
                return '竞赛尚未开始!';
            }
        }

        let where = {
            ANSWER_CATE_ID: String(cateId),
            ANSWER_USER_ID: userId,
            ANSWER_TYPE: 1,
            ANSWER_DAY: timeUtil.time('Y-M-D')
        }
        let cnt = await AnswerModel.count(where);
        if (cnt >= dayCnt) {
            return '每日竞赛答题最多' + dayCnt + '次，请明日再来！';
        }

        return '';
    }

    async saveMyAnswer(userId,
     ) { 
     
    }

    // 随机N条记录，生成本次题库
    async genQuestion(userId, type, cateId) { 

        return { questionList: [], maxTime:10 };
    }


    async getMyAnswerList(userId, {
        search, // 搜索条件
        sortType, // 搜索菜单
        sortVal, // 搜索菜单
        orderBy, // 排序 
        page,
        size,
        isTotal = true,
        oldTotal
    }) {

        orderBy = orderBy || {
            'ANSWER_ADD_TIME': 'desc'
        };
        let fields = 'ANSWER_SCORE,ANSWER_CATE_NAME,ANSWER_TYPE,ANSWER_ADD_TIME,ANSWER_CNT,ANSWER_PER,ANSWER_SUCC_CNT,ANSWER_DURATION,ANSWER_START,ANSWER_END';

        let where = {};
        where.and = {
            ANSWER_USER_ID: userId,
            _pid: this.getProjectId() //复杂的查询在此处标注PID
        };

        if (util.isDefined(search) && search) {
            where.or = [

            ];
        } else if (sortType && util.isDefined(sortVal)) {
            // 搜索菜单
            switch (sortType) {
                case 'type': {
                    where.and.ANSWER_TYPE = Number(sortVal);
                    break;
                }
                case 'cateId': {
                    where.and.ANSWER_CATE_ID = String(sortVal);
                    break;
                }
                case 'sort': {
                    orderBy = this.fmtOrderBySort(sortVal, 'ANSWER_ADD_TIME');
                    break;
                }
            }
        }

        return await AnswerModel.getList(where, fields, orderBy, page, size, isTotal, oldTotal);
    }

git代码

点击下载

在可观测性场景中，Elasticsearch 常受限于写入性能与高昂成本。在《可观测性方案怎么选？SelectDB vs Elasticsearch vs ClickHouse》一文中提到， 在云上日志服务中，SelectDB 相比 Elasticsearch 展现出明显的性能和成本优势。为进一步探索，本文通过基准测试对比二者表现，验证 SelectDB 在日志场景下性能与成本上的显著优势。1、基准目标和方法本次测试的目的是在可观测性场景下公平比较 SelectDB 和 Elasticsearch 的实际性能和成本，并为用户提供参考数据。为尽可能做到真实和公平，我们设计了如下对比测试：测试环境：使用 腾讯云 Elasticsearch 和 SelectDB Cloud 进行测试，未进行任何针对性调优。测试数据：使用 Elasticsearch 的官方性能测试集http logs，以确保测试中立性（实际更偏向 Elasticsearch）。测试内容：写入性能、查询性能、存储空间和成本的比较，这些是可观测性场景中用户最关心的指标。测试方法：第一阶段比较相同资源下的性能第二阶段比较支持相同负载所需的成本。第二阶段超越了传统的性能测试，以验证性能优势是否能在实际用户需求中转化为成本优势，而不仅仅是一种推断。2、相同资源下的性能比较在测试的第一阶段，比较相同配置下 Elasticsearch 和 SelectDB 的性能和成本。第一步：Elasticsearch 和 SelectDB 分别购买具有相同配置（48vCPU、348GB RAM）的集群，成本分别为 18.83 元/小时 和 16.95 元/小时。（1）腾讯云 Elasticsearch（48c） 费用：

（2）SelectDB Cloud（48c） 费用：

第二步：在 Elasticsearch 中创建索引，并在 SelectDB Cloud 中创建表。为确保公平性，两个系统使用相同的模式，包括字段类型、索引类型、共享/分片数量等。需要注意的是，Elasticsearch 的索引大致对应于 SelectDB 的表。第三步：将相同的 HTTP 日志数据集导入到 Elasticsearch 和 SelectDB Cloud。Elasticsearch 耗时 225 秒，而 SelectDB Cloud 仅需 69 秒。SelectDB Cloud 比 Elasticsearch 快 3.3 倍。第四步：分别在 Elasticsearch 和 SelectDB Cloud 中运行 HTTP 日志测试集的查询。Elasticsearch 中的首次运行（冷查询）耗时 2.049 秒，第二次运行（热启动）耗时 1.691 秒，SelectDB Cloud 中的首次运行（冷查询）耗时 0.599 秒，第二次运行（热启动）耗时 0.52 秒。SelectDB Cloud 在冷查询和热启动时的速度均比 Elasticsearch 快 3 倍以上。第五步：分别获取 Elasticsearch 和 SelectDB Cloud 的存储空间使用情况。Elasticsearch 的存储空间使用量为 12.8GB，而 SelectDB Cloud 的存储空间使用量为 3.3GB。与 Elasticsearch 相比，SelectDB Cloud 的存储空间减少了 75%。通过本次测试可以看出，在相同配置下，SelectDB Cloud 的数据导入性能比 Elasticsearch 快 3.3 倍，查询性能快 3 倍以上，存储空间减少 75%。这意味着，在相同配置下，SelectDB Cloud 的用户将比使用 Elasticsearch 的用户获得数倍的性能提升。在可观测性场景下，用户更关心相同负载和性能下能否真正降低成本。因此，接下来的测试将验证 SelectDB Cloud 的性能优势能转化为多大的实际成本优势。3、成本突破：从性能领先到真正的成本降低在测试的第二阶段，SelectDB Cloud 将缩小至其原始规模的 1/6，与使用 6 倍资源的 Elasticsearch 进行性能比较。第一步：将 SelectDB Cloud 48vCPU 的集群规模缩减至 8vCPU，成本也大幅降低至 2.93 元/小时。

第二步：在仅有 8vCPU 的 SelectDB Cloud 集群中创建相同的表。第三步：将相同的 HTTP 日志数据集导入到具有 8vCPU 的 SelectDB Cloud 集群中。这一过程耗时 140 秒，速度仍比 48vCPU 的 Elasticsearch 云集群快 1.6 倍。第四步：在 8vCPU 的 SelectDB Cloud 集群中运行来自 HTTP 日志测试集的查询。第一次运行（冷查询）耗时 1.389 秒，第二次运行（热启动）耗时 1.246 秒。8 vCPU 的 SelectDB Cloud 在冷查询时比 48vCPU 的 Elasticsearch 还快 47.5%。在第五步中，获取 8vCPU SelectDB Cloud 集群中的存储空间使用情况。SelectDB Cloud 的存储空间使用量仍为 3.3GB，比 Elasticsearch 低 75%。通过本次测试可以看出，在将 SelectDB Cloud 的资源缩减至 Elasticsearch 的 1/6 后，成本仅为 2.93 元/小时，比 Elasticsearch 的 18.83 元/小时 节省了 85% 的费用。尽管成本大幅降低，但性能仍保持显著优势：数据导入性能快 1.6 倍，冷查询性能快 47.5%，存储空间减少 75%。这意味着，对于从 Elasticsearch 切换到 SelectDB Cloud 以支持相同负载的用户来说，SelectDB Cloud 将实现实打实的 83% 成本降低，并提供更好的性能。4、为什么 SelectDB 能如此显著地降低成本SelectDB Cloud 出色的性能和成本优势得益于针对可观测性场景进行的广泛优化。SelectDB 针对日志场景优化倒排索引降低空间占用，数据和索引均采用列式存储，并使用 ZSTD 压缩算法，实现了高压缩率，可大幅减少存储空间。此外，SelectDB 将所有数据存储在低成本的对象存储中，热数据在 SSD 等本地磁盘上进行缓存和加速，利用可观测性数据冷热分层的特点降低存储空间单价。这些特性使 SelectDB 的存储成本比 Elasticsearch 降低了接近一个数量级。 SelectDB 采用存储与计算分离的架构。在写入数据时，计算层仅存在一次计算消耗，避免了 Elasticsearch 存储与计算一体化架构所需的多副本。此外，SelectDB 为日志和追踪等时间序列数据设计了时间序列压缩策略，将后台数据合并的写入放大从 3 降低到 1，大幅节省计算和 IO 资源消耗。SelectDB 专为实时分析而设计，这意味着它支持高性能聚合操作，这些操作常用于可观测性领域。在搜索查询方面，SelectDB 以一种针对日志搜索和topn查询（如SELECT * FROM log WHERE message MATCH 'error' ORDER BY time DESC LIMIT 100）进行优化的方式实现了倒排索引。结果是，SelectDB 在搜索查询方面速度快 2 倍，在聚合查询方面速度快 10 倍。结论在 HTTP 日志基准工作负载下，SelectDB Cloud 与 Elasticsearch 相比实现了 83%的成本降低。在实际生产环境中，许多用户已经在 PB 规模下用 SelectDB 或 Apache Doris 取代了 Elasticsearch，实现了显著的成本节约。您可以阅读来自网易、MiniMax、领创集团、中信信用卡中心的用户故事来了解更多。我们建议您根据实际业务场景设计测试，亲自验证 SelectDB 在成本与性能上的表现。欢迎申请 SelectDB Cloud 试用验证。

阿里云函数计算 AgentRun 正式推出全新 知识库功能，为智能体（Agent）注入更强的语义理解与上下文感知能力。通过深度集成 百炼知识库 与 RAGFlow 知识库，AgentRun 让开发者能够轻松构建具备“知识”的智能应用，真正实现“更懂用户、更贴场景、更高效响应”。

为什么需要知识库？

在传统智能体开发中，模型往往依赖通用训练数据，缺乏对特定业务、私有文档或实时信息的理解能力。这导致其在面对专业领域问题、企业内部知识或个性化需求时表现受限。

AgentRun 的知识库功能正是为解决这一痛点而生——它将外部知识源无缝接入智能体运行流程，通过 检索增强生成（RAG） 技术，让智能体在回答问题、执行任务时，能动态调用相关知识，大幅提升准确性、专业性与可信度。

双引擎支持：百炼 + RAGFlow，覆盖多元知识形态

百炼知识库绑定

函数计算AgentRun可以绑定您账号下已经创建好的阿里云百炼知识库。

进入到创建页面，输入知识库名称、描述，选择知识库类型为“百炼”，可以多选绑定您账号下已经在阿里云百炼控制台创建好的多个知识库。填写检索配置后，点击创建知识库，即可将您的阿里云百炼知识库绑定至AgentRun平台。

RAGFlow知识库绑定

函数计算AgentRun可以绑定您账号下已经创建好的RAGFlow知识库。如果您没有RAGFlow知识库，可以点击此链接，一键在SAE上创建RAGFlow。

进入到创建页面，输入知识库名称、描述，选择知识库类型为“RAGFlow”，填写您已部署的RAGFlow的BaseURL、Dataset IDs和API-KEY（将其保存在凭证中）。填写检索配置后，点击创建知识库，即可将您自建的RAGFlow知识库绑定至AgentRun平台。

RAGFlow知识库详细配置获取方式，可参考此文档。

三大集成方式，灵活适配各类开发场景

函数计算AgentRun 知识库功能支持快速创建集成、代码集成和MCP集成三种方式，满足不同技术栈和开发习惯。

快速创建Agent集成知识库功能

对于希望快速验证想法或加速产品迭代的团队，AgentRun 提供了低代码、可视化的知识库绑定能力。开发者只需登录 AgentRun 控制台，选择已创建的百炼或 RAGFlow 知识库，将其关联到目标智能体，并配置简单的检索参数（如返回结果数量、相似度阈值等），即可完成集成——全程无需编写一行代码。

这一模式极大降低了技术门槛，让产品经理、运营人员甚至非技术背景的创新者也能参与智能体的构建与优化。无论是搭建内部知识问答机器人、客户自助服务助手，还是快速验证某个垂直领域的 AI 应用场景，都能在几分钟内完成部署并上线试用。

代码集成知识库查询能力对于追求极致灵活性与控制力的开发者，AgentRun 提供了原生代码级知识库接入能力。您可以在代码逻辑中，调用AgentRun SDK的知识库检索接口，根据业务上下文动态发起检索请求，精准筛选并注入最相关的信息片段到智能体的推理流程中。您可以使用AgentRun SDK，调用以下封装的接口，进行单知识库查询或多知识库查询。

fromagentrun.knowledgebaseimportKnowledgeBase
## 获取单知识库，进行查询
knowledgebase=KnowledgeBase.get_by_name("ragflow-test")
single_kb_retrieve_result=knowledgebase.retrieve("<your-query>")
print(single_kb_retrieve_result)
## 获取多知识库，进行查询，支持跨供应商知识库类型检索
multi_kb_retrieve_result=KnowledgeBase.multi_retrieve(
    query="<your-query>",
    knowledge_base_names=["ragflow-test","<your-knowledge-base-name-2>"],
)
print(multi_kb_retrieve_result)

同样，您可以集成LangChain框架，将知识库的查询能力集成在工具或上下文中。

"""AgentRun 知识库智能体集成代码示例

使用前，请参考https://docs.agent.run/docs/tutorial/quick-start 配置好相应认证信息和环境变量

curl http://127.0.0.1:9000/openai/v1/chat/completions -X POST \
    -H "Content-Type: application/json" \
    -d '{"messages": [{"role": "user", "content": "什么是Serverless?"}], "stream": true}'
"""

import json
import os
from typing import Any

from langchain.agents import create_agent
import pydash

from agentrun import Config
from agentrun.integration.langchain import model
from agentrun.integration.langchain import knowledgebase_toolset
from agentrun.integration.langgraph.agent_converter import AgentRunConverter
from agentrun.knowledgebase import KnowledgeBase
from agentrun.server import AgentRequest, AgentRunServer
from agentrun.server.model import ServerConfig
from agentrun.utils.log import logger

# 请替换为您已经创建的 模型 名称
AGENTRUN_MODEL_SERVICE = os.getenv("AGENTRUN_MODEL_SERVICE", "<your-model-service>")
AGENTRUN_MODEL_NAME = os.getenv("AGENTRUN_MODEL_NAME", "<your-model-name>")
KNOWLEDGE_BASES = os.getenv("AGENTRUN_KNOWLEDGE_BASES", "ragflow-test").split(",")

if AGENTRUN_MODEL_NAME.startswith("<") or not AGENTRUN_MODEL_NAME:
    raise ValueError("请将 MODEL_NAME 替换为您已经创建的模型名称")

## 加载知识库工具，知识库可以以工具的方式供Agent进行调用
knowledgebase_tools = []
if KNOWLEDGE_BASES and not KNOWLEDGE_BASES[0].startswith("<"):
    knowledgebase_tools = knowledgebase_toolset(
        knowledge_base_names=KNOWLEDGE_BASES,
    )
else:
    logger.warning("KNOWLEDGE_BASES 未设置或未替换，跳过加载知识库工具。")

agent = create_agent(
    model=model(AGENTRUN_MODEL_SERVICE, model=AGENTRUN_MODEL_NAME, config=Config(timeout=180)),
    tools=[
        *knowledgebase_tools,   ## 通过工具集成知识库查询能力
    ],
    system_prompt="你是一个 AgentRun 的 AI 专家，可以通过查询知识库文档来回答用户的问题。",
)


async def invoke_agent(request: AgentRequest):
    messages = [
        {"role": msg.role, "content": msg.content}
        for msg in request.messages
    ]

    # 如果配置了知识库，查询知识库并将结果添加到上下文
    if KNOWLEDGE_BASES and not KNOWLEDGE_BASES[0].startswith("<"):
        # 获取用户最新的消息内容作为查询
        user_query = None
        for msg in reversed(request.messages):
            if msg.role == "user":
                user_query = msg.content
                break

        if user_query:
            try:
                retrieve_result = await KnowledgeBase.multi_retrieve_async(
                    query=user_query,
                    knowledge_base_names=KNOWLEDGE_BASES,
                )
                # 直接将检索结果添加到上下文
                if retrieve_result:
                    messages.append({
                        "role": "assistant",
                        "content": json.dumps(retrieve_result, ensure_ascii=False),
                    })
            except Exception as e:
                logger.warning(f"知识库检索失败: {e}")

    input: Any = {"messages": messages}

    converter = AgentRunConverter()
    if request.stream:

        async def async_generator():
            async for event in agent.astream(input, stream_mode="updates"):
                for item in converter.convert(event):
                    yield item

        return async_generator()
    else:
        result = await agent.ainvoke(input)
        return pydash.get(result, "messages[-1].content", "")


AgentRunServer(
    invoke_agent=invoke_agent,
    config=ServerConfig(
        cors_origins=[
            "*"
        ]
    ),
).start()

注意⚠️：如果您选择了RAGFlow的知识库，需要确保您的Agent运行环境和RAGFlow的BaseURL的地址处于同一网络环境下，否则AgentRun SDK将无法调用RAGFlow的API实现查询能力。

通过代码集成，AgentRun 赋予开发者“全栈可控”的能力——既享受函数计算的弹性与免运维优势，又保留对智能体认知过程的深度掌控，真正实现“知识为我所用，逻辑由我定义”。

MCP集成：将知识库检索作为Agent的工具调用

AgentRun知识库率先实现“Agentic RAG”（智能体RAG）模式——将传统静态检索升级为动态、可编程的智能体工具调用。具体而言，用户可一键将知识库发布为MCP，使其成为大语言模型（LLM）可主动调用的工具之一。在此模式下，LLM不再被动接收上下文，而是具备“工具使用能力”，在推理过程中自主判断何时调用RAG、数据库查询、库存检查等工具，并基于返回结果进行多步推理与任务分解。这种机制使RAG从单一检索功能转变为智能体工具箱中的灵活组件，与其他工具并列协作，显著提升复杂任务的处理能力。其工作方式更贴近人类“思考—行动—反思”的认知流程：模型先分析问题，制定计划，再按需调用多个工具获取信息，最终整合结果生成答案。

进入其他 >> 工具管理 >> 工具市场，可以搜索到“AgentRun知识库MCP” 工具模板，点击安装后，填写知识库名称和类型，即可将知识库的查询能力一件发布成MCP工具给大模型进行调用。

创建完毕后，点击工具详情，即可看到集成调用的工具地址：

基于MCP工具标准协议，AgentRun 支持以标准化方式对接知识库服务，实现跨平台、跨模型的上下文注入能力，保障架构的开放性与可扩展性。

结语：从“能回答”到“真理解”，智能体正在拥有“知识之眼”

AgentRun 知识库功能的上线，不仅是一次技术能力的升级，更标志着智能体发展迈入新阶段——从依赖通用语料的“泛化应答”，转向基于专属知识的“情境理解”。当智能体能够随时调用企业文档、行业规范、用户历史甚至实时数据，它便不再只是一个语言模型的接口，而成为一个具备领域认知、上下文记忆与决策依据的数字协作者。

未来，随着知识库的持续进化——支持多模态内容、动态更新、跨源推理——AgentRun 将进一步降低构建“有知识、有逻辑、有温度”智能体的门槛。

我们相信，真正的智能，不在于模型有多大，而在于是否“懂你所需、知你所问、信你所依”。

AgentRun，正让每一个智能体，学会思考，更学会理解。

一、ArkUI框架概述

ArkUI是OpenHarmony生态中核心的UI渲染框架，采用声明式开发范式，支持多设备（手机、平板、PC等）多端统一开发。开发者通过ArkTS语言描述界面，框架负责组件树构建、布局测量、渲染绘制及事件处理。底层由方舟运行时引擎驱动，协同无障碍、国际化等系统能力，保障高性能与良好用户体验。

二、开发范式与执行机制

1. 开发范式
   当前ArkUI中主流的开发范式采用ArkTS声明式范式，支持多端统一UI描述。在一些需要更高性能的场景下，可以采用Native API进行开发。

2. 代码执行流程
   ETS源码经IDE编译生成ABC中间指令文件，打包成HAP安装包。应用启动时，原能力子系统启动对应应用进程，ArkUI子系统负责组件创建与渲染，最终由图形侧执行渲染指令，完成界面展示。
   

   三、渲染核心流程与状态管理

3. 组件树构建
   框架在运行时维护组件树的压栈与出栈，动态构建UI组件树结构。
   
4. 布局测量与渲染绘制
   父节点传递约束条件，子节点自底向上计算尺寸和位置，完成布局测量。随后根据信息发送渲染指令，执行绘制操作，生成最终界面。
   
5. 差异更新机制
   通过装饰器（如@State、@Provider）实现状态观察，观察过程识别“脏”组件，即需要更新的组件。
   ArkUI区分两类“脏”状态：
6. 布局脏：影响尺寸和位置，需重新测量布局，以及判定影响范围。

7. 绘制脏：仅影响样式，重绘但不重新布局。
   
   状态变更触发依赖收集，精准标记相关组件为脏，在布局过程只更新需要刷新的组件，避免造成组件树的重建。

   四、ArkUI应用开发性能优化方案

   1、创建过程优化
   方案1：使用组件懒加载机制，减少创建数量，提升响应速度。在滚动过程中进行数据读取和加载，使用LazyForEach仅渲染可视区域项，避免一次性数据加载过多，解决页面加载耗时长问题，关于长列表优化可以参考长列表加载丢帧优化。
   
   方案2：高负载场景分帧渲染，将本来一帧内加载的数据分成多帧加载，但是分帧渲染需要开发者计算每帧中加载多少数据，操作复杂，因此在必要的情况下才推荐使用。详请可点击查看。
   

2、布局过程优化
方案1：精简组件数量，使用扁平化布局组件（如RelativeContainer、Grid）替代多层Column/Row嵌套，减少中间节点数量。

方案2：利用布局边界减少布局计算
①对固定尺寸组件设置具体宽高，限制布局影响范围。
②优先使用无状态组件@Builder替代@Component，减少状态依赖。

3、更新过程优化
复用替代重建, 利用组件复用机制，减少滑动过程中组件创建、布局开销，提升帧率。

4、状态管理优化
可以采用状态管理V2进行开发，状态管理V2相对于状态管理V1优化了更新方式，由V1的对象级观察，优化为属性级观察，可以降低状态更新时带来的开销。详细内容参考：状态管理V2。

五、工具链支持与性能分析

推荐使用DevEco Studio内置工具：

• AppAnalyzer：实现“体检-报告-修复”一体化流程，快速定位布局耗时及性能瓶颈。
• 通过工具量化指标，结合业务场景，精准实施优化策略。
  
• ArkUI Inspector：用于可视化的展示UI组件树，分析UI的布局层次和参数。使用方法可以参考ArkUI Inspector使用说明
• CPU Profiler：Profiler：用于在运行过程中抓取trace和调用栈对耗时点进行分析，使用方法可以参考CPU Profiler的使用指导分析的思路可以参考常用Trace的含义。

六、性能标准与实践建议

• 帧率要求：120fps设备单帧耗时≤8ms，90fps设备单帧耗时≤12ms。
• 响应速度：页面跳转及交互反馈延迟需低于用户感知阈值，保证流畅体验。
  实践中应结合懒加载、分帧渲染、组件复用、扁平化布局及状态管理优化等多种手段，综合提升应用性能和用户体验。

七、总结

ArkUI框架通过声明式开发范式和高效的状态管理机制，实现了灵活且高性能的UI渲染。性能优化需基于框架运行机制，结合具体业务场景，重点控制组件数量、优化更新粒度、合理利用复用与懒加载策略。借助DevEco Studio提供的丰富工具链，开发者可快速定位性能瓶颈，持续提升鸿蒙应用的流畅度和响应速度。

八、更多参考

1、界面渲染性能优化
2、AppAnalyzer

所有人【华为专家面对面01期】ArkUI框架运行原理与常见性能优化方案 

了解ArkUI渲染的基本流程，探索通过节点优化、懒加载、预加载、组件复用等技术手段,提升列表场景下应用的流畅度，打造极致流畅的界面体验。
➡️ 详情点击

不会吧，你不会现在写代码还是靠拼时长吧，不会吧？

我曾经也认为，优秀的后端工程师就是写得快、写得多。直到我发现，我把大量时间浪费在了配置环境、用Print查Bug、以及手动排查内存泄漏上。

真正的效率提升，不仅仅是手速变快了，今天分享8个彻底改变我开发逻辑的工具，它们把我的焦虑变成了生产力。

ServBay：我再也不想在本地环境上浪费一秒钟

说实话，每次接手新项目或者维护老项目，最让我头疼的不是代码逻辑，而是 Go 环境配置。

以前为了跑一个老项目，我得去改 .bash_profile，去整 GOPATH，甚至因为版本冲突把本地环境搞得一团糟。如果是混合技术栈，比如还得跑个Java服务，那简直是灾难。

而 ServBay，它就是拯救我于水深火热中的。它能够了一键安装，多版本共存。我可以同时保留 Go 1.11 和最新的 Go 1.24。

现在，环境配置对我来说就是点一下鼠标的事。这种隔离且并存的能力，让我工作效率蹭蹭的。

Delve：求求大家，别再用Print调试了

曾几何时，我也是Print党。遇到Bug，就在代码里疯狂塞 fmt.Println("111")、fmt.Println("here")。

但在Go的高并发场景下，这种做法是一时爽，事后火葬场。Goroutine一多，控制台输出乱成一锅粥，根本看不出谁先谁后。

Delve 能够仔细剖析正在运行的程序。

不需要修改代码，直接启动调试：

dlv debug main.go

遇到死锁或者逻辑诡异的地方，打个断点，直接看内存里的变量状态。它能清晰地展示出每一个Goroutine停在哪里。自从用了Delve，我解决并发Bug的时间从半天缩短到了几分钟。

Cobra：写出让人想用的CLI工具

以前写内部脚本，我总是偷懒直接解析 os.Args。结果就是，过了一个月，连我自己都忘了参数顺序是怎样的，同事用起来更是怨声载道。

后来我强制自己用 Cobra， 它是Kubernetes都在用的库。用它写出来的工具，天生就带有规范的帮助文档（--help）和子命令结构。

看看这个架子，写出来就显得很专业：

package main

import (
        "fmt"
        "github.com/spf13/cobra"
)

func main() {
        var rootCmd = &cobra.Command{
                Use:   "deploy",
                Short: "一键部署工具",
                Run: func(cmd *cobra.Command, args []string) {
                        fmt.Println("正在执行部署逻辑...")
                },
        }
        // 哪怕只是个内部工具，也要像模像样
        rootCmd.Execute()
}

把烂脚本变成正规军，Cobra是门槛最低的选择。

GoVet：编译通过不代表逻辑正确

编译器只能告诉我们语法没错，但它不管逻辑是不是弱智。

我有一次在 if 条件里把 == 写成了 =（虽然Go通常会报错，但在某些特定构造下容易混淆），或者在循环里错误地使用了闭包变量，导致线上数据全错。

GoVet 就是为了拦截这种低级但致命的错误存在的。

go vet ./...

它专门扫描那些“看起来对，但执行起来会炸”的代码。比如 Printf 的参数类型不对，或者不可达的代码块。现在我把它做进了提交前的钩子（Pre-commit hook），不通过Vet检查的代码，根本不允许提交。

Golangci-lint：我的全自动代码洁癖管家

团队协作最怕什么？怕每个人的代码都有自己的想法。

与其在Code Review时因为“花括号换不换行”或者“变量名太短”吵架，不如直接上 Golangci-lint。

它不是一个工具，它是一个聚合器，并行跑了50多个检查器。

golangci-lint run

配置好 .golangci.yml 后，它就是就是一个无情的检查机器。未使用的变量、过高的圈复杂度、拼写错误，它全能抓出来。它让Code Review回归到了关注业务逻辑本身，而不是纠结语法细节。

Pprof：甚至能看清内存的毛细血管

服务上线后CPU突然飙高，或者内存缓慢泄漏，这时候看日志是没用的。以前我只能靠猜，现在我靠 Pprof。

只需要在代码里加一行副作用引入：

import _ "net/http/pprof"

然后启动个HTTP服务，就能通过浏览器看到程序的X光片。

我也经常用命令行来生成火焰图：

go tool pprof -http=:8080 http://localhost:6060/debug/pprof/profile

哪一行代码占用了最多的CPU，哪个对象在这个瞬间分配了最多的内存，一目了然。不夸张地说，Pprof 给了我一种“上帝视角”。

Godotenv：别把秘密写在代码里

有些初级事故是因为把数据库密码或者AWS Key直接硬编码在代码里，然后推到了Git仓库。

Godotenv 是我所有项目的标配。

开发时，我只需要在本地建一个 .env 文件：

DB_SECRET=123456
DEBUG_MODE=true

代码里直接读：

import "github.com/joho/godotenv"

func init() {
    // 自动加载，从此告别硬编码
    _ = godotenv.Load() 
}

这样既方便本地调试，又彻底杜绝了泄密风险。

Gosec：上线前的最后一道防线

即便有了前面的工具，安全漏洞依然防不胜防。比如随机数生成器用得不安全，或者TLS配置太弱。

人工审查很难发现这些隐患，但 Gosec 可以。

它会扫描代码的抽象语法树（AST），专门寻找安全漏洞。

gosec ./...

它会直接甩一份报告给我，告诉我哪一行代码可能导致SQL注入，哪里的文件权限设置太宽泛。对于金融类或者对安全性要求高的项目，这是必须要跑的流程。

低效是一种选择，而你本可以拒绝

开发者的黄金时间极其有限。是用这仅有的精力去和环境配置搏斗、去肉眼查错，还是把它们交给工具，自己专注于构建复杂的系统逻辑？

这不只是工具的差异，这是职业生涯的加速度差异。

从今天开始，选两个装上，别让重复劳动毁了你的创造力。

一、Oracle数据库故障描述
一个Oracle数据库故障表现为ASM磁盘组掉线，ASM实例无法挂载（mount）。数据库管理员自行进行简单修复，未能成功，随后联系北亚数据恢复中心恢复数据。

二、Oracle数据库故障分析方法
北亚企安数据恢复工程师先对底层磁盘展开分析，从组成ASM磁盘组的磁盘中提取ASM元数据作进一步研究。经分析发现，ASM存储元数据已损坏，这就是diskgroup无法挂载的原因。接着，北亚企安数据恢复工程师重组ASM存储空间，导出其中的数据库文件，再对导出的文件进行检测与恢复。若检测显示数据文件完整，后续可直接用其启动数据库；若文件也损坏，则需对底层文件进行解析和恢复。

三、Oracle数据库数据恢复过程
1、按上述方法分析和提取底层数据，得到ASM元数据，借助其重组出ASM存储空间。
2、得到ASM存储空间后，使用北亚自主开发的ASM解析工具（也可用其他常见工具或自编脚本）解析ASM结构，目的是获取ASM中的数据文件。

3、对提取的Oracle数据库文件进行检测。
检测结果：

4、利用北亚自主开发的oracle数据库解析工具，解析所有数据文件中的数据记录，然后按用户需求导入到新数据库中。

四、Oracle数据库数据恢复成功
通过重组ASM存储空间、对ASM磁盘底层解析，导出恢复后的数据库文件，并进一步对这些文件进行底层解析，再按用户要求将数据导入新数据库。北亚企安数据恢复工程师抽查数据表验证恢复数据，未发现异常，随后通知用户方进行全面数据验证，结果显示数据恢复完整，本次Oracle数据库数据恢复成功。

如果你也在折腾“让大模型在本地改代码”的 Agent，八成遇到过这种崩溃瞬间：模型说要执行命令、工具跑完回传一大坨、上下文越滚越长、性能忽高忽低、最后还把权限问题搞成“你敢让我删库我就敢执行”……😅

OpenAI 的 Codex CLI（本地跨平台软件代理）把这套流程摊开讲得很直白：核心就是 agent loop（代理循环）——一个负责“用户 ↔ 模型 ↔ 工具”编排的 harness。把 loop 设计对了，Agent 才不会像一只喝了三杯咖啡的无头苍蝇。

下面就用更接地气（但依然严谨）的方式，把 Codex 的 agent loop 彻底“拆开看看”，顺便给做 Java/Python 工程化的同学一些能直接落地的套路。

1）所谓 Agent Loop：其实就是“反复问、反复干、反复追加”的流水线

Codex 这套 loop 的节奏非常规律：

1. 收用户输入：把用户的话塞进要发给模型的 prompt（注意：真实 prompt 不是一段字符串，而是“多条消息/多种 item 的列表”）。
2. 模型推理（inference）：把 prompt 送到模型，让模型输出。

3. 分支：模型输出要么是

   • 最终回复（assistant message）：这回合结束；
   • 工具调用（tool call）：比如让 agent 执行 ls、读文件、跑测试等。
4. 执行工具 + 追加结果：agent 执行工具，把工具输出追加回 prompt，再请求模型下一轮推理。
5. 循环直到停止调用工具：最后必须以 assistant message 收尾（哪怕主要产出是“本地代码改动”）。

一回合（turn）里可能有很多次“推理↔工具”迭代；多回合（multi-turn）则会把历史对话都带上，prompt 越滚越长：

这也解释了为什么 Agent 工程化最容易踩的坑，永远是这两座大山：

• 性能（请求体越来越大，推理越来越贵，缓存还经常失效）
• 上下文窗口（context window）不够用（尤其单回合工具调用特别多的时候）

2）Codex 如何“组装 prompt”：不是你以为的一段文本，而是一串分角色的 item

Codex CLI 用的是 Responses API，而不是让用户直接手搓 prompt。用户提交的 JSON 里最关键的三块是：

• instructions：系统/开发者指令（Codex 既支持用户配置，也有模型内置 base instructions）
• tools：可调用的工具定义列表（Codex 内置 shell、plan 等，也可接 MCP 工具，甚至用 web_search）
• input：多条 item 的数组（消息、文件、图片、推理结果、工具调用/输出等都在这里）

Codex 会先往 input 里插入一堆“铺垫项”，再追加用户的真实提问。典型的插入顺序包含：

• developer 消息：权限/沙箱说明（只约束 Codex 自带的 shell 工具）
• developer 消息：用户自定义 developer_instructions（可选）
• user 消息：用户指令聚合（可选）（例如 AGENTS.md/AGENTS.override.md、skills 等）
• user 消息：环境上下文（cwd、shell 等）

示例（权限/沙箱说明）：

<permissions instructions>
  - description of the sandbox explaining file permissions and network access
  - instructions for when to ask the user for permissions to run a shell command
  - list of folders writable by Codex, if any
</permissions instructions>

示例（环境上下文）：

<environment_context>
  <cwd>/Users/mbolin/code/codex5</cwd>
  <shell>zsh</shell>
</environment_context>

而真正发到 Responses API 的 input item，是这种结构：

{
  "type": "message",
  "role": "user",
  "content": [
    {
      "type": "input_text",
      "text": "Add an architecture diagram to the README.md"
    }
  ]
}

另外，Codex 还会把工具定义塞到 tools 里，长得大概这样（里面同时包含 shell、plan、web_search、以及 MCP 工具）：

[
  // Codex's default shell tool for spawning new processes locally.
  {
    "type": "function",
    "name": "shell",
    "description": "Runs a shell command and returns its output...",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "command": {"type": "array", "description": "The command to execute"},
        "workdir": {"description": "The working directory..."},
        "timeout_ms": {"description": "The timeout for the command..."}
      },
      "required": ["command"]
    }
  },

  // Codex's built-in plan tool.
  {
    "type": "function",
    "name": "update_plan",
    "description": "Updates the task plan...",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {"plan": "...", "explanation": "..."},
      "required": ["plan"]
    }
  },

  // Web search tool provided by the Responses API.
  { "type": "web_search", "external_web_access": false },

  // MCP server tool (example).
  {
    "type": "function",
    "name": "mcp__weather__get-forecast",
    "description": "Get weather alerts for a US state",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {"latitude": {}, "longitude": {}},
      "required": ["latitude", "longitude"]
    }
  }
]

Codex 文章里还有几张“prompt 快照”的图，直观看出服务器会把 system、tools、instructions、input 组装成最终 prompt：

3）流式推理 + 工具回填：SSE 事件才是“真实对话记录”

Codex 发起一次推理，Responses API 会用 SSE（Server-Sent Events）流式返回事件；这些事件不仅用来 UI 实时输出，还会被 Codex 转成内部对象，并追加回 input，供下一轮推理继续使用。

示例（SSE 事件流片段）：

data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
data: {"type":"response.reasoning_summary_text.done", "item_id":...}
data: {"type":"response.output_item.added", "item":{...}}
data: {"type":"response.output_text.delta", "delta":"forty-", ...}
data: {"type":"response.output_text.delta", "delta":"two!", ...}
data: {"type":"response.completed","response":{...}}

如果模型输出了 function_call，Codex 执行工具后会把 推理摘要、函数调用、函数输出 一股脑追加回下一次请求的 input，示例：

[
  /* ... original items ... */
  {
    "type": "reasoning",
    "summary": [
      {"type": "summary_text", "text": "**Adding an architecture diagram for README.md**\n\nI need to..."}
    ],
    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
  },
  {
    "type": "function_call",
    "name": "shell",
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
    "call_id": "call_8675309..."
  },
  {
    "type": "function_call_output",
    "call_id": "call_8675309...",
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
  }
]

对应的第二张快照图：

当模型终于输出 assistant message（不再请求工具）时，这个 turn 才算结束：

data: {"type":"response.output_text.done","text":"I added a diagram to explain...", ...}
data: {"type":"response.completed","response":{...}}

用户再发一句话，就进入下一 turn：需要把上一次 assistant message 和本次 user message 一起追加进去：

[
  /* ... all items from the last request ... */
  {
    "type": "message",
    "role": "assistant",
    "content": [{ "type": "output_text", "text": "I added a diagram to explain the client/server architecture." }]
  },
  {
    "type": "message",
    "role": "user",
    "content": [{ "type": "input_text", "text": "That's not bad, but the diagram is missing the bike shed." }]
  }
]

第三张快照图更能说明：这玩意儿会一直长一直长……

4）性能：请求体“看似二次方”，但缓存命中能救命

很多同学看到“每次把所有历史 input 都带上”第一反应：这不就是网络传输二次方增长吗？ 没错。

Responses API 支持 previous_response_id 来减少重复传输但Codex 当前选择不用它，主要为了两点：

• 保持请求无状态：对 API 提供方更友好。
• 支持 ZDR（Zero Data Retention）：不在服务端存历史数据，避免与“零数据保留”冲突；同时 reasoning 的 encrypted_content 允许服务端解密以保留“模型理解”，但不持久化用户数据本身。

真正的性能关键在于：prompt caching。缓存命中要求非常苛刻：必须是精确的前缀匹配。因此缓存命中要求非常苛刻：必须是精确的前缀匹配。因此) Codex 特别强调“旧 prompt 是新 prompt 的 exact prefix”，这不是强迫症，是省钱省到骨子里了😂。

哪些变化会导致 cache miss？

• 中途改 tools（甚至工具顺序不稳定都会炸）
• 改 model（模型内置指令变了）
• 改沙箱配置、审批策略、cwd 等

Codex 的一个经典教训：早期接入 MCP 工具时，因为 工具枚举顺序不一致 导致缓存频繁失效（工具数量一多，直接“性能心电图”📉）。

为了尽量保住前缀，Codex 对“中途配置变更”的处理是：追加新消息，而不是修改旧消息：

• 沙箱配置/审批模式变化：追加新的 developer <permissions instructions>
• cwd 变化：追加新的 user <environment_context>

这招非常值得抄作业：你改的是“环境状态”，但你不能动 prompt 的“历史前缀”。

5）上下文窗口：不够用怎么办？压缩（compaction）才是正解

Agent 聊着聊着就爆 context window，这事不是“会不会发生”，而是“什么时候发生”。Codex 的策略是超过阈值就 compact：把冗长的 input 替换成一个更短、但能代表历史的 item 列表，让后续推理还能“记得发生过啥”。

早期需要手动 /compact；后来 Responses API 提供了专门的 compaction endpoint：
https://platform.openai.com/docs/guides/conversation-state#co...

它会返回一组可直接替代原 input 的 items，其中包含 type=compaction 以及不透明的 encrypted_content，用于保留模型的“潜在理解”。Codex 现在会在超过 auto_compact_limit 后自动触发这件事。

6）给做 Java/Python 工程化 Agent 的“抄作业清单”✅

把 Codex 的设计拆完，可以总结出几条非常硬核、非常工程的结论：

1. 把 prompt 当“不可变日志”来设计
   追加新事件，不修改旧事件。你改旧的，缓存就没了；你改多了，定位就疯了。
2. 工具列表要稳定排序 + 版本可控
   工具顺序不稳定 ≈ 主动放弃缓存。生产环境别玩“每次启动动态扫描全部工具再随机排列”的刺激游戏。
3. 权限/沙箱必须写进 prompt
   这不是文档，这是模型行为约束的一部分。尤其是 shell 这类高危工具，不写清楚“哪些目录可写、何时需要用户确认”，迟早出事故。
4. 流式事件要落地成结构化记录
   SSE 不只是展示给用户看的“打字效果”，而是下一轮推理的输入材料。要能回放、能审计、能复现。
5. 上下文管理要有自动化机制
   compaction 不是锦上添花，是续命针。阈值触发、摘要策略、加密理解保留，都是工程必须项。

当 Agent loop 真正做对了，你会发现“让模型写代码”不再是玄学，更像一套可控的流水线：可追溯、可审计、可缓存、可压缩、可扩展。

而 Codex 把这套“写代码的 AI 代理”最核心的一环——loop——摊开讲清楚了：所谓智能体，很多时候并不是模型多聪明，而是 harness 多靠谱。

（Codex 开源仓库： https://github.com/openai/codex ）

喜欢就奖励一个“👍”和“在看”呗~