在人类数十万年的进化历程中，文字书写与阅读的出现仅数千年，而语音和视觉始终是我们最高频的沟通方式。

因此，仅依赖文本交互的AI产品已远不足以满足需求，各大企业对于AI在语音侧“接口”的争夺也从未停止，原因如下：

1. 单位时间信息密度：人们说话的速度远超打字，语音交互能大幅提升信息输入与输出的整体效率。
2. 数据价值：日常沟通中蕴含着大量有价值的信息。过去这些口头交流往往无法沉淀为数据资产，而语音AI可以将“声音”数字化，进而转写成文本甚至结构化的知识。
3. 市场价值：据预测，2025年全球语音识别市场规模可达约267.9亿美元，该技术正广泛应用于汽车、医疗、消费电子等诸多行业。
4. 其他潜在因素……

基于此，钉钉在前两个月的十周年发布会上推出了其首款AI语音产品——钉钉A1。起初我并未拿到实体硬件，推测当时可能仍是原型机阶段，而在最近的发布活动中终于成功上手体验。

我们首先看看官方对其的定位：会议助手、销售助手、客服助手……

钉钉A1的核心功能与应用场景

A1的技术实现逻辑相对清晰：它借助钉钉最新发布的DingTalk_AI（原先可能称为AI听记），将录制下的语音实时转写成文字，并通过大模型进行总结与提炼。

可以简单理解为，硬件部分充当了一个语音输入设备，而DingTalk_AI则是一个功能展示模块。现阶段，无论是会议、面试还是销售拜访，该设备都能自动整理关键要点，生成纪要和分析报告。

例如，人力资源专员借助A1记录面试过程后，可在钉钉内查看自动提炼的候选人履历、情绪状态、沟通能力分析等内容，辅助其快速筛选合适人才。

针对客户服务交流，A1能够提取客户基本信息、需求分类及满意度指标，帮助客服人员更清晰地了解服务质量与改进方向。

之所以能处理这些看似“需求百变”、“杂乱无章”的场景，是因为A1内置了超过30种场景化的AI纪要模板，覆盖学习笔记、日常记录、会议纪要、面试记录等多种情况，用户只需选择相应模板即可生成结构清晰的总结。

但我们之前提到：A1本质上是一套硬件输入、平台处理的系统。从逻辑上讲，钉钉完全可以将这个处理模块开放出来，让各类企业在其基础上开发出丰富多彩的应用！例如：

1. 销售或客服的对话记录可被提炼为潜在的销售线索和客户意向分析；
2. 人力资源部门的面试记录可衍生出详细的候选人评估报告；
3. 行政人员的会议记录则可自动转化为任务清单和日程安排；
4. 其他各类定制化需求均可被实现。

这意味着，目前大家在A1上所见的所有功能或许只是一个初步示范，未来基于此平台的各类应用都有可能出现。与其说A1是一个单纯的AI语音产品，不如将其定义为一个AI语音开放平台。

按照这一发展趋势，A1的硬件设备成本可能会逐渐降低，甚至未来几十元即可购得，毕竟它已成为钉钉生态体系中不可或缺的重要组成部分。

与微软Nuance的对比分析

如前所述，A1给我的初始印象其实可以独立于钉钉生态存在，但置于钉钉生态下，其价值则显得尤为独特。

在使用A1的过程中，我第一时间联想到的是微软此前收购的一款产品——Nuance（2022年以970亿美元收购）：

在国内，与之功能类似的产品包括左手医生开发的听诊机器人：

Nuance在AI技术加持下，在医疗问诊环节展现出巨大的想象空间。它能有效协助医生工作，降低误诊率，同时减轻医生在处理文书类工作时的压力。

根据微软发布的相关数据，Nuance已帮助超过600家医疗机构的医生，平均每次问诊节省约5分钟时间，超过70%的临床医生反馈因使用该AI工具而减轻了职业倦怠感，整体产品口碑颇为良好。

然而，尽管Nuance估值很高，但由于数据安全与合规考量，其产品并未在国内广泛落地。而国内一些类似设备往往体积庞大、成本较高，不利于大规模部署，因此近年来在医疗场景中，成熟的语音交互设备仍较为少见。

正因如此，当看到钉钉A1时，我便自然联想起之前的医疗业务场景。从逻辑上讲，A1具备平替潜力，但这不仅需要在应用层进行针对性改造，也对硬件在嘈杂环境下实现精准的多人语音识别能力提出了更高要求。

目前看来，钉钉依然聚焦于办公场景发力。从各类宣传口径来看，A1被明确界定为**“随身办公AI”**，旨在通过轻量硬件结合云端大模型，为职场中的多元角色赋能。

这无疑是合理的策略，因为不同领域的知识在进行语义识别时存在专业门槛。例如，Nuance在医疗领域的优势源于其多年的专业语料积累和算法优化，能够精准识别医学术语和医生的口述习惯，并支持个性化的模板与术语库。

A1若要达到类似水平，不仅需要大量底层基础设施支撑，也需要先在办公场景完成验证与迭代，进而将此类能力以接口形式开放给更多行业与企业。

颇具潜力的是，从现有布局看，阿里巴巴集团似乎确实具备实现这一切的综合能力。

阿里技术栈如何赋能A1平台

阿里生态之所以能够支撑A1从“功能硬件”跃升为“开放平台”，关键在于其形成了完整的技术闭环，这是大多数单一硬件厂商或纯软件服务商难以复制的优势。

阿里巴巴拥有从底层算力（如含光芯片、平头哥半导体）、云计算基础设施（阿里云），到中间层算法（达摩院多模态大模型、语音识别引擎），再到上层应用（钉钉、天猫精灵等）的全栈技术布局。

这意味着A1的语音处理流程可以得到深度优化与定制！

以近期颇受关注的医疗AI产品为例：蚂蚁阿福，其月活跃用户已超过1500万，每日处理健康咨询问题超500万次。虽然这主要面向消费者市场，但未来未必不能向专业领域延伸，毕竟平台已积累了海量的用户健康数据。

总而言之，钉钉A1及其背后的开放平台构想确实充满想象空间，但市场竞争态势同样不容忽视。

语音AI的未来展望与挑战

除了钉钉A1与微软Nuance，当前语音AI的主流形态大致可分为两条路线：办公效率提升型与消费生活助理型。

在国内市场，科大讯飞的听见产品及智能办公本代表了会议生产力路线：以高精度语音转写为技术底座，叠加说话人分离、智能纪要/待办事项/思维导图等结构化输出功能，并强化私有化部署与数据加密能力，着力解决政府、企业及涉密场景中“能用且敢用”的核心问题。

值得注意的是，讯飞在该领域实力雄厚，仅就说话人分离技术的成熟度便需要长期积累。

当然，这个赛道上巨头云集，包括钉钉、腾讯会议、飞书等均在此布局。

在消费端，家庭物联网入口的路线则较为清晰：即通过结合语音交互、人工智能与智能家电，构建一体化的“家庭管家”生态。这类需求虽非刚需，但随着技术普及和消费升级，其市场存在必然性，可视为高端消费场景的延伸。

最后需要指出，语音类AI产品乃至开放平台拥有广阔的发展前景，对于底层基座模型而言，这也是其多模态能力的重要延伸。

然而，此类产品要真正站稳脚跟，仍需跨越几道关键门槛：嘈杂环境下的多人语音分离与识别精度、企业级数据安全与合规要求、以及针对不同行业术语与工作流程的深度适配能力。

办公场景作为一个高价值且相对标准的起点，钉钉A1做出了不错的尝试。下一步，能否将其核心能力开放给生态伙伴，让更多企业“在其基础上玩出花样”，将是决定该平台发展上限的核心因素。

如果说过去的语音产品竞争焦点是识别准确率，那么未来的比拼将转向：谁能将语音真正转化为生产力工具，谁能将生产力工具进一步平台化、生态化。 AI语音的故事，或许才刚刚拉开序幕……

熟悉我的朋友可能知道，我去年在AI to B领域的创业未能成功。今年，我将精力主要放在了三个业务方向上：AI英语学习工具“空气小猪”、AI实战训练营以及AI领域的猎头服务。

之所以能开展AI猎头服务，原因其实很直接：

1. 首先，我积累了大量相关领域的人才资源。
2. 其次，去年从事2B业务时，我服务了许多不同规模的公司，了解他们的需求。
3. 最后，今年运作的训练营也培养并输送了不少AI人才。

因此，无论是人才的供给端，还是企业的需求端，我都有比较深入的了解。从实际数据来看，我成功推荐了近20位人才，其中年薪最高的接近百万元，较低的也有30万元左右。

单从数据上看，似乎猎头业务的整体收益相当可观，应该加大投入力度。然而，真实的业务开展却远比想象中复杂，可以说是机遇与挑战并存。

曾有一家客户需要招募中高端AI人才。我这边恰好有一位来自阿里巴巴、职级为P8的学员，无论是能力还是背景都非常匹配，于是便将他推荐了过去。

然而，这位人才入职不到两个月就选择了离职，并且无论是用人单位还是他本人，都给出了非常负面的反馈。

最近一段时间的市场情况则更加令人困惑。不止一家公司向我咨询，希望招募AI工程师或产品经理，其中甚至有两家公司正在大规模裁员！

我们根据他们的要求筛选并推荐了几位候选人，得到的反馈却都是“不合适”。这让我感到十分不解。因此，我们不禁要问：在当前环境下，企业自以为需要什么样的AI人才？他们实际上又需要什么样的人才？为什么许多看似合适的人才最终却无法稳定留下？

企业以为的AI人才需求与实际差距

首先，我们来看看各家公司认为自己需要什么样的人才。以下是两个真实的职位描述（JD）：

如果仅从表格中的描述来看，企业的需求似乎非常清晰。当前，市场对AI应用工程师的需求尤为迫切，并且在许多公司里，AI应用工程师与AI产品经理的职责范围和工作内容出现了高度重合的趋势。

近期，不少粉丝朋友频繁询问公众号中自动聊天功能的实现方法，他们同样希望拥有类似功能。为了避免重复回答，我今天特地为大家整理了一份详细攻略。

本文基于公众号内容创作者的实际运营需求，详细讲解如何利用腾讯元器构建一个可持续运行的公众号智能体。通过零代码配置，该平台能够将公众号历史文章自动转化为知识库，持续处理粉丝的高频咨询，实现内容检索、固定问答与智能回复。在实际应用中，它能显著降低重复人工回复的成本，让创作者将时间重新聚焦于内容创作与深度思考。

最近一次团队聚餐时的闲聊，我们探讨了一个现实话题：**AI究竟为工作效率带来了多少提升？**产品同事的回答非常直接：至少十倍。原因很简单：他日常需要收集、整理并反复查阅大量文字资料，如果依靠人工处理，不仅速度慢，还伴随显著的学习成本。这句话深深触动了我。

自从开始创业并独立运营公众号以来，我最深刻的体会是：**时间被无限碎片化，但每项任务都必须完成。**一方面，内容创作需要完整且安静的思考时间；另一方面，公众号后台源源不断的私信咨询亟待回复。其中许多问题高度重复，但不回应就会影响粉丝体验，甚至直接增加取关风险。坦白说，在这种状态下，创作者很容易被“回应用户”这件事拖慢节奏，反而难以专注于内容质量的提升。

需要一个AI客服

我也曾尝试过解决方案。之前折腾过公众号智能体，希望用AI分担部分咨询压力，但现实是：搭建流程复杂、数据需要自行整理、还需反复调试。当然，最主要的障碍在于整个生态问题——脱离公众号生态，处理效率低下，最终效果不理想，反而增添了额外负担。

后来我意识到，我真正需要的不是一个功能强大的AI，而是一个无需我额外付出学习成本的工具。既然要对公众号，腾讯的产品展现出独特的生态优势：腾讯元器。

腾讯元器

腾讯元器给我的第一印象并非功能繁多，而是它从一开始就站在普通内容创作者的视角进行设计。整个过程几乎不涉及代码，不要求用户理解模型、向量或工作流，将原本只有技术团队才能驾驭的内容，简化为几个明确的操作步骤。

特别是对公众号而言，它最关键的优势在于：**内容无需重新整理。**只需一次授权，就能将公众号历史文章直接作为智能体的知识来源；后续新文章发布，也会自动同步更新。这意味着：公众号本身，就是一套持续生长的知识库。

更重要的是，智能体并非“搭建完成即可闲置”的工具。基于成熟的检索与问答机制，它可以长期稳定地承接粉丝的高频咨询，将大量重复问题拦截在前端，让我能把时间重新拉回到内容创作与思考本身。在发布与使用层面，腾讯元器也几乎没有额外的割裂感：智能体可以直接运行在微信体系内，与公众号、客服、小程序等场景天然打通，而不是先制作一个工具，再想办法“接入”生态。

你的公众号智能体

**腾讯元器更适合长期运行，也更适配公众号内容创作者。**下面我将通过实践，快速搭建一个适配个人IP的公众号智能体。

AI客服的必要性

对于知识分享类公众号运营者来说，真正的痛点不在于“是否拥有AI”，而在于：**能否低成本、低门槛地将多年积累的内容，通过AI发挥出更大价值。**许多公众号KOL在长期运营过程中，已经沉淀了大量高质量文章，但这些内容往往仅停留在“被动阅读”阶段，无法被高效复用。

与此同时，微信后台每天都会收到大量重复性私信咨询：不回复会影响用户体验，逐条回复又极其耗时。长期下来，甚至可能导致用户流失。

AI客服为什么难以落地？

理论上，“AI客服+知识库”是一个理想的解决方案，但实际落地时问题却接踵而至。

第一，数据整理成本极高：手动保存文章、导出后再导入知识库，耗时耗力，极易中途放弃。

第二，搭建门槛并不低：需要理解流程、编写提示词、调整参数并发布上线，对非技术背景的公众号运营者并不友好；此外，不少平台存在使用费用，进一步放大了试错成本。即便是成本较低的扣子智能体，也需要资源点才能正常使用。

而腾讯元器恰恰在这些关键节点上，实现了“降维解决问题”。

接入端：一键授权，直接使用内容

• 支持一键授权拉取公众号历史文章。
• 直接作为知识库数据源。
• 新文章自动每日更新。

也就是说：无需手动整理数据，无需反复维护知识库，公众号本身就是一个“持续生长”的知识源。

搭建端：零代码，模板化

腾讯元器主打简单易用、零代码：提供【一键同款智能体模板】，并配有清晰的配置指引。用户只需根据公众号定位：1. 修改提示词；2. 选择数据源，就能快速完成专属智能体的搭建。

腾讯元器几乎没有使用成本

在发布和使用上，腾讯元器完整打通了微信生态：可一键发布到公众号、小程序，发布后有明确的接入与配置说明，整体流程非常顺滑。更重要的是：在腾讯生态内使用，模型token完全免费，这极大降低了公众号运营者尝试和长期使用AI的成本。

之前我也在其他平台（例如扣子智能体）尝试过类似方案，但从“方便程度”和“落地效率”来看，腾讯元器更像是一个为公众号场景量身定制的原生解决方案。它并非让你“学会做AI”，而是让你用AI将已有内容的价值真正释放出来。接下来具体说明操作步骤。

1. 创建智能体

登录腾讯元器官网：👉腾讯元器-AI智能体创建与分发平台

https://yuanqi.tencent.com/?yq_channel_id=61000021

选择公众号智能体。公众号智能体可以简单理解为：**一个熟悉你公众号历史文章的“博主分身”。**随后，需要根据你的“人设”来设计这个智能体应用。

2. 创建知识库

创建成功后可以看到：公众号文章已被自动识别并转化为知识库，完全省去了自行整理文章的环节。如果文章风格差异较大，也可以进行分类处理。

文档标签是什么？

官方解释是：文档标签用于给文档打标签，可在知识库检索范围设置中通过参数控制不同用户查询不同内容。通俗来说：文档标签等于给知识库内容分组，用以控制“这次提问能查阅哪一部分资料”。

目前这个场景下我们暂不需要文档标签，因此不展开详述。知识库更新频率选择自动更新，腾讯元器会在每天3:00前拉取前一天的文章作为新增内容。

3. 模型选择

公众号智能体授权成功后，进入首页。我选择的是DeepSeek模型，原因很简单：DeepSeek对中文进行了针对性优化，在中文场景下输出质量更稳定。

4. 提示词编写（核心环节）

提示词建议使用Markdown格式，模型理解效果更好。官方推荐结构如下：

#角色名称：  
#风格特点：  
#输出要求：  
#能力限制：  
能够达成以下用户意图  
##意图名称：  
##意图描述：  
##意图示例：  
##意图实现：

插入符合我们公众号IP的提示词示例：

### 提示词（Prompt）  
  
**#角色名称**  
小钗管理助手：一个专注于管理实践与职场成长的智能助理，负责基于公众号「小钗说管理」的内容，为用户提供清晰、可落地的管理思路与建议。  
**#风格特点**  
表达理性克制、逻辑清晰，语言通俗但不浮夸；偏重方法论与实际经验，不灌鸡汤，不使用夸张营销语；必要时会通过反问或拆解问题，引导用户思考管理本质。  
**#输出要求**  
* 使用中文回答  
* 单次回复控制在 300 字以内  
* 结构清晰，可使用简短分点，但避免过度格式化  
* 回答应贴近真实管理场景，优先结合实践经验说明  
* 不虚构不存在的案例或数据  
**#能力限制**  
* placeholder=不提供法律、财务、心理治疗等专业领域的权威结论  
* placeholder=不对企业具体内部决策承担责任  
* placeholder=不进行个人隐私、组织敏感信息分析  
---  
**能够达成以下用户意图**  
  
### ##意图名称  
  
管理问题咨询与方法建议  
  
### ##意图描述  
  
用户在团队管理、员工沟通、执行力、绩效管理或个人职场成长中遇到具体困惑，希望获得可操作的管理思路或分析建议。  
  
### ##意图示例  
  
* “下属执行力差，总是拖延怎么办？”  
* “作为新晋主管，如何建立威信？”  
* “团队里能力强但难沟通的人该怎么管理？”  
  
### ##意图实现  
  
* 先判断问题属于【人】【事】【机制】哪一类  
* 必要时通过简短反问澄清背景（如管理层级、团队规模）  
* 给出不超过 3 点的核心建议，并说明适用前提  
* 避免绝对化结论，强调“具体情境需要调整”  
---

把提示词交给AI一键优化

将我们的提示词让AI一键优化。优化后的提示词会更贴合微信公众号的回复逻辑，例如：自动增加回复字数限制、控制单次输出长度、避免回复内容过多导致公众号消息被截断。对于公众号智能体来说，这一步至关重要，能显著提升实际使用体验。

近来，不少求职者在应聘AI应用工程师、Agent应用工程师或AI产品经理等岗位时，常常遇到一个高频面试问题：

ReAct究竟是什么？它主要用来解决什么问题？

坦白说，这个问题涵盖的范围相当广泛，作为常规岗位的面试题可能不太适宜。

但请注意，这绝不意味着ReAct不重要。恰恰相反，ReAct本身极为关键，只是要透彻理解它，几乎需要梳理清楚整个Agent的架构体系，因此大多数应聘者很难给出令人满意的答案。

另一方面，对于多数从业者而言，这个词显得较为**“低频”**。这是因为许多（中小型）公司的负责人引入Agent概念更多是为了融资或宣传，并非真心打算将其应用于实际生产环境，导致许多同学缺乏相关的实践机会。最终结果是：

大多数人仅仅通过文章有所耳闻，整体认知非常模糊。 那么，ReAct到底是什么？

ReAct = Reason（推理） + Act（行动），这是由Google和普林斯顿大学的研究人员在2022年提出的一种范式：

1. 推理（Reasoning）： 驱使大语言模型思考“为何”以及“如何”执行某项行动。
2. 行动（Acting）： 驱使大语言模型执行具体行动，并与外部环境进行交互。
3. 循环反馈： 通过观察行动结果来驱动下一步的推理过程。

简单翻译就是：先思考，再行动。但这似乎仍未彻底解答其必要性、本质内涵及实现方法，因此我们需要追根溯源。

为何需要ReAct框架？

从模型能力的演进历程来看，我们旨在解决大语言模型**“只能思考与言说，无法实际操作”** 的固有局限。

在此背景下，Function Calling（函数调用）或Model Context Protocol（MCP）等概念应运而生。其基本模式是预先定义一系列工具并将其挂载到模型（请求）上，每次由模型根据用户问题与工具参数（如描述、名称等）来判断是否需要调用特定工具。

以经典问题**“成都最近两天天气怎么样？”** 为例，若期望模型自动调用工具，通常需要如下配置：

# 将“工具”挂载到模型上：此处是一个 get_weather 函数
{
"type": "function",
"function": {
    "name": "get_weather",
    "description": "查询未来几天某个城市的天气预报",
    "parameters": {
      "type": "object",
      "properties": {
          "city": {
            "type": "string",
            "description": "城市名，例如：成都"
          },
          "days": {
            "type": "integer",
            "description": "查询多少天的预报（1-7天）"
          }
      }
      "required": ["city", "days"]
    }
  }
}

在基本交互模型确立之后，问题接踵而至：真实应用场景中工具数量庞大、用户提问模糊不清、用户意图复杂多样…

总而言之，所有难题叠加在一起，可以归结为一句话：模型在工具调用方面的表现不尽如人意。

于是，思维链CoT（Chain-of-Thought） 技术登场了。它要求模型对用户问题进行深入分析，将复杂问题分解为一系列小步骤（对应小工具调用），然后观察这些工具依次执行，成功完成一步再进行下一步，期望借此提升整体AI产品的用户体验。

在日常生活中，您通常如何寻找免费的电子书资源呢？事实上，许多流通的免费电子书可能涉及盗版内容。阅读本身是一种高尚的精神活动，因此我们强烈建议读者尽可能支持正版书籍。值得欣喜的是，支持正版很多时候并不需要直接付费，而是可以通过合法渠道获取丰富资源。

今天，我们将详细介绍一个由官方推出的数字图书馆——首都图书馆电子资源平台。该平台提供完全免费的阅读服务，涵盖133万册电子书、1.5万册有声读物、1500种期刊、50余种报纸、795.8万篇学术论文以及超过5000部视频资料。

此外，平台还拥有大量双语绘本资源，这尤其适合家中有孩子的父母。接下来，我们将逐步说明如何获取并使用这些免费资源，建议您收藏本文以备后续参考。

首都图书馆的官方网站很容易找到，直接通过搜索引擎即可访问。首先，请在浏览器中打开首都图书馆的官网页面。

进入官网后，注意页面右上角有一个小人形状的图标，点击该图标即可进入登录界面。

在登录框中输入读者卡号、密码及验证码，即可使用站内所有资源。但这里存在一个常见问题：网页端未提供新用户注册入口。那么，新用户该如何获得平台电子书资源呢？

针对新用户，需要先通过移动端完成注册。请打开微信，搜索并进入“首都图书馆”小程序，点击右下角的“我的”按钮，然后选择页面上方的“绑定读者卡”。接着点击“快速注册”选项，填写个人基本信息即可成功申请读者账户。

完成注册后，返回电脑端的登录界面，输入刚才申请的读者卡账号和密码进行登录。

登录成功后，点击页面上方的“资源”栏目，然后选择您感兴趣的类别。如果您身处外地，可以直接点击“馆外访问”选项以使用相关资源。

筛选后，页面将显示所有支持馆外访问的资源库。首都图书馆接入了众多第三方资源库，点击任一资源库的“馆外访问”链接后，系统可能会要求再次输入首图账号密码以验证身份。

如果您需要为孩子寻找绘本资源，可以点击“少儿”分类。目前支持馆外访问的少儿资源库包括书童AR互动科普教育资源库、新东方双语阅读平台以及中少快乐阅读平台。

书童AR互动科普教育资源库以虚拟展馆的形式呈现内容，用户可以直接搜索或选择不同主题进行浏览学习。

新东方双语阅读平台的内容非常全面，提供中文绘本、英文绘本、趣听绘本等多种类型，资源格式涵盖图书、音频和视频。

每本图书通常分为四个学习板块：绘本阅读、名师精讲、跟读训练和趣味练习，旨在提供多维度的学习体验。

以上展示的仅是首都图书馆电子资源的冰山一角。事实上，全年龄段读者都能在这里找到所需或感兴趣的内容，无论是期刊杂志、学术论文还是文学小说，各类阅读需求均可满足。

最后需要提醒的是，通过首都图书馆界面跳转至第三方资源库时，可能需要重新输入账号进行验证。请务必使用首都图书馆的读者证账号，不要输入错误信息，也不要因为需要重复登录而放弃使用。

近期，一篇题为《几乎都在挂羊头卖狗肉，AI Agent的泡沫现在到底有多大？》的文章，以中肯但略带悲观的角度探讨了AI Agent的现状，引发了广泛讨论。该文章具有较高的参考价值，它系统梳理了多位行业一线实践者对通用Agent的认知与看法。

正如原文所指出的，作者以Manus的新产品Wide Research及其公司跑路、撤资事件作为切入点，深入剖析了国内外Agent领域泡沫化乱象的具体表现、背后的驱动因素以及未来的生存法则。在与多位偏向实践导向的技术专家交流后，我发现他们对AI发展的认知呈现出高度的一致性。以下是我对这些关键观点进行的进一步解读与拆解。

类Manus产品崛起的背后原因

在深入分析之前，我们必须清醒地认识到：今年Agent概念的爆火，首要原因在于大模型的基础能力取得了显著提升，其次才是在此基础上工具调用（tool-use）方面取得的关键性突破。

大模型主要负责解决任务规划与调度问题，因此，类Manus的AI产品能够爆发的核心驱动力正是模型能力的跨越式增强。 工具链则致力于解决多模态交互问题，包括近期备受关注的MCP（Model Context Protocol）和Computer Use，本质上都是AI多模态能力的延伸，旨在攻克AI在听觉、视觉、触觉等领域的各种“能力短板”。

而通常所说的记忆与反馈迭代机制，则完全属于数据工程的范畴。这类技术过去常被称为RAG（检索增强生成），近期或许又多了一个称谓——上下文工程。优秀的数据工程能够有效减轻模型的幻觉问题。记忆体系过去难以实现，如今变得可行的根本原因在于模型上下文长度得到了极大扩展，从当前趋势看，突破百万上下文长度指日可待。

综上所述，Agent得以发展的根本源泉在于模型底层能力的增强。 在此基础之上，才催生了工具链的繁荣景象：“从编程接口到浏览器使用（browser-use），再到计算机操作（computer-use），随着MCP这类通用接口普及率的提高，Agent的工具调用能力不断增强，使其能够更高效地从外部获取信息并与各类系统进行交互。”

下图可以更清晰地展示，今年Agent的爆发实质上是工具链能力与AI模型能力叠加的结果：

不过，需要指出的是，通用Agent依赖于browser-use或computer-use，在某种程度上是一种无奈之举，因为许多网站并未提供标准的API接口。

XX-use未必是最优解决方案

理想情况下，我们应优先让Agent调用那些受控、可测试、可审计的标准化函数（例如通过MCP），而将Computer Use仅作为兜底的备用能力。

例如，我们团队此前进行过一个简单的实践验证：《Coze+Claude实现Manus》。在这个尝试中，我们并未使用Computer Use，一方面因为应用场景足够聚焦和单一，另一方面也是希望验证基于AI编程（利用Claude模型生成代码）这种方式的可行性。

大家可以设想，当AI编程能力变得更加强大、模型的理解能力进一步提升时，整个Agent的架构或许就能形成闭环。这很可能解释了为何许多科技巨头都在密切关注这一领域：谁掌握了AI编程能力，谁就掌控了智能体能力扩展的“总开关”。这不再是简单地开发一个应用程序，而是在构建一个能够自主生长和演化应用的底层平台。

这契合了OpenAI、Google等行业巨头“让模型吞噬一切”的终极路线图。然而，这条道路上的安全性问题与实现难度极高，仍有漫长的征程需要跋涉。

与此同时，业界也涌现出许多消极的评判声音。

行业内的消极声音

尽管这可能不够公平，但Manus已然成为通用Agent的典型代表，也成为了主要的批评对象。

从业者王显指出：“Manus前阵子刚推出的新功能Wide Research，我认为其竞争力非常弱，对提升产品核心竞争力几乎没有助益。” 他的后续观点更为尖锐：“Manus从创立至今，从产品设计的思路来看，是完全失败的。” 在他看来，早期采用广泛而浅层的策略获取用户尚可理解，但长期而言，这种模式无法抵御大型模型厂商的业务下沉以及垂直领域专业厂商的渗透侵蚀。

行业的观点比较一致地聚焦于 “能否真正解决实际问题” ：

1. 当用户面临真正复杂、棘手的现实问题时，这类通用Agent往往仍然无能为力；
2. 当一个Agent宣称自己能够处理所有事务时，它在任何一个特定领域通常都无法做到极致；
3. ……

上述观点或许有些过于激烈，因为通用Agent无疑代表着一个重要的技术发展方向，只是当前的表现尚未达到预期。

其中有一句评论尤为关键：“Manus仍然未能解决场景壁垒的构建问题。” 它缺乏专业的领域数据、专属的工具链、行业认可的认证、与具体业务的深度绑定集成，也没有切入高价值的业务场景，简而言之，任何人都可以模仿实现。因此，它更偏向于工程能力的横向扩展，而非在构建深厚的场景护城河。

任何人都能实现，意味着其构建成本相对不高。但 “成本不高”是相对的，即便是垂直领域的Agent也会遭遇以下共性挑战：

1. 精准的意图识别：用户的需求常常是模糊且充满歧义的。智能体必须理解用户的“言外之意”，这是提升用户体验的关键门槛，需要极其精细的提示工程（Prompt Engineering） 和大量高质量的对话数据进行调优。
2. 强大的工具生态：智能体的能力边界由其能够调用的工具决定。一个“类Manus”产品能否真正解决问题，取决于它能否高效使用各类服务（如预订票务、查询邮件、控制智能家居、分析数据等）。自建工具链成本高昂，因此，与第三方服务的集成能力变得至关重要。
3. 深厚的领域知识：在垂直领域，通用知识远远不够。必须将行业的SOP（标准作业程序）、私有数据库、专家经验等注入到智能体中。这部分工作是繁琐且需要深耕的“脏活累活”，没有捷径可走，但正是构建竞争壁垒的核心所在。

这也正是红杉资本等机构高度推崇OpenEvidence的原因：AI应用的竞争重点，已经从纯粹的技术能力比拼，转向了产品定义、用户体验打磨、生态整合以及垂直行业知识深度的竞争。早期的市场红利，属于那些在垂直领域做得无比深入、构建了坚实壁垒的团队。

既然如此，通用Agent尚不成熟，为何仍能吸引众多追捧者？

资本追捧与市场期待

王显甚至认为，这场通用Agent泡沫的兴起，是创业公司与资本市场共同推动的产物：

“Manus根本不是在认真打磨产品，而是在执行一套资本运作的路线，通过持续推高市场声量以获得更高额的融资。至于创始人在获得融资后，是真正深入场景做产品，还是卷款跑路，只有创始人自己清楚。从产品角度看非常失败，但从营销角度看却可以说非常成功。”

另一位从业者张森森表示：“国内很多Agent产品功能堆砌繁多，但基本都属于快速拼凑，痛点把握不够聚焦。” “例如，大量集成了文案撰写、PPT制作、资料查询、图片生成等功能的产品层出不穷，其中不乏大厂参与。它们都具有通用Agent的特点：功能广泛但都不精通。写代码准确率不高，数据分析缺乏可解释性，设计产出质量参差不齐。初次使用或许能带来新鲜感，但若想长期依赖则难以实现。它们很少能产出明确与工作流、KPI绑定的、可交付的确定结果。”

……正如各位业内人士所言，通用Agent确实尚不成熟，那么大家追捧的原因何在？这里提供一个真实案例：前两个月，我的一位担任某公司高管的好友，他们公司开发了一款类Manus产品。正当他私下向我吐槽产品毫无壁垒、一个月就匆忙上线、幻觉问题严重时，他们的老板却果断决定All In投入！原因无他，仅仅因为 马化腾为他们的产品点了赞！ 你觉得产品怎么样并不重要，资本市场的看法才至关重要。并且，正因为这类产品构建成本相对较低，创业公司就更乐意投身其中。

另一方面，我所在的一个AI训练营中，有位学员刚刚成功融资一亿元，他们从事的是垂直领域的Agent创业。即便在那个看似细分的领域，许多Manus遇到的问题，他们几乎全都遭遇了：

1. “产品的宣传能力与实际交付能力之间存在显著落差，并非能力完全无用，而是存在明显的期望差距；”
2. “成功演示的往往是任务中那20%的标准化、流程化部分，而真正构成工作核心的，是那80%的、充满各种‘长尾异常’和复杂多变的现实状况。”

从这些角度来看，原始文章的分析确实非常客观和深入。

总而言之，我从中得出的结论是：作为既得利益者，通用Agent的推崇者们绝不会主动承认自身的不足；而资本的参与者对于它们暂时是否真的‘可行’并不十分关注，反正他们自认为是最了解AI趋势的一批人，相比其他赛道，他们在这个领域取得成功的概率似乎更高。

接下来，我们将开始探讨Agent存在缺陷的根本性原因。

Agent缺陷的深层根源

对于这部分论述，我特别认同郭炜的观点：“很多Agent公司并没有真正沉下心来，深入到具体的用户场景中去进行深耕。”

不过，对于其原因，我有更深的感触：当前国内的创业生存环境异常严峻，以我自身的创业经历为例：

1. 耗时3个月才拿下电信业务经营许可证，使得APP终于得以正式上线；
2. 历时6个月，算法备案至今尚未完成，导致核心的AI功能模块一直无法开放；
3. ……；

不得不说，国内针对创新型AI业务的创业环境确实存在诸多挑战，这在客观上加剧了创业者们对 “快速获得投资”的渴望。这导致了一个现象：即使我们明知通用Agent目前存在诸多问题，但为了迎合资本市场的偏好，也不得不投入资源做一个类似的产品。很坦诚地说：我们计划在11月发布的产品中也会包含一个Agent模块，并且我们并不指望它解决所有问题，但在那20%我们精心设计并要求的核心场景中，我们会竭力确保它表现优异！

近日，一篇题为《几乎都在挂羊头卖狗肉，AI Agent的泡沫现在到底有多大？》的文章引发了广泛关注。该文观点较为中肯，同时也流露出对当前Agent发展态势的悲观情绪。

此文颇具价值，它系统梳理了多位身处行业一线的实践者对“通用Agent”这一概念的认知与看法。

文章以Manus公司的新产品“Wide Research”及其后续的撤资风波为切入点，深入剖析了国内外AI Agent领域存在的泡沫化乱象、其背后的深层成因以及参与者们未来的生存法则。

在与数位注重实践的技术专家交流后，我发现他们对AI现状的判断高度一致。以下是我对这些关键观点的一些延伸解读与拆解。

类Manus产品为何兴起？

在深入讨论之前，我们必须清醒地认识到一个基本事实：今年Agent概念之所以大火，首要前提是大模型的核心能力取得了跨越式进步，其次才是在此基础上，工具调用（tool-use）等层面实现了关键性突破。

大模型负责解决任务规划与调度等复杂问题。因此，Manus这类AI产品能够爆发，最根本的驱动力在于模型本身能力的质变。

工具链则致力于解决多模态交互与信息获取问题。无论是近期热门的MCP（模型上下文协议），还是Computer Use（计算机使用）概念，本质上都是AI多模态能力向外延伸的体现，旨在弥补AI在听觉、视觉、触觉等感知与操作层面的不足。

至于记忆与反馈迭代机制，则主要归属于数据工程的范畴。过去我们常称之为RAG（检索增强生成），近来也可能被称作上下文工程。精良的数据工程能有效为模型“投喂”准确信息，从而显著降低其产生“幻觉”的概率。

记忆体系过去难以实现，如今变得可行，其核心原因在于模型的上下文窗口长度得到了极大扩展。就目前趋势来看，突破百万上下文长度指日可待。

综上所述，Agent能够从概念走向实践，根基在于模型能力的增强。

在此基础之上，工具链的繁荣才得以显现：“从代码生成到浏览器使用（browser-use），再到计算机使用（computer-use），伴随着MCP这类通用接口的普及，Agent的工具调用能力得以强化，能够更高效地从外部获取信息，并与各类系统进行交互。”

下图可以更清晰地展示，今年Agent的爆发实质上是工具链与AI能力叠加的结果：

不过需要指出的是，通用Agent普遍采用browser-use或computer-use的方式，某种程度上也是一种无奈之举，因为大量网站并未开放规范的API接口。

“XX-use”并非万能钥匙

理想状态下，我们更希望Agent调用的是受控、可测试、可审计的标准函数（如通过MCP），而将Computer Use这类“黑盒”操作仅作为最后的兜底方案。

该项目就未使用Computer Use，一是因为应用场景足够单一明确，二是我们想验证基于AI生成代码（使用Claude）这一技术路径的可行性。

可以想象，当AI编程能力变得更强大、理解更精准时，整个Agent的架构可能实现自我闭环。这或许也是众多科技巨头密切关注该领域的原因：谁掌握了AI编程能力，谁就掌握了智能体能力扩展的“总开关”。这不再是开发单一应用，而是在构建一个能够自主生长应用的生态平台。

这符合OpenAI、谷歌等巨头“让模型吞噬一切”的终极愿景。然而，这条路径上的安全性挑战与实现难度极高，仍有漫长的道路需要探索……

与此同时，业内也涌现出许多消极的批判声音。

审视：来自业内的消极声音

尽管可能不够公允，但Manus已然成为通用Agent的代名词，也成了众矢之的。

从业者王显指出：“Manus前阵子刚推出的新功能Wide Research，我认为竞争力非常弱，对提升产品核心价值帮助不大。”

他的进一步观点更为激烈：“Manus从始至终，在产品设计思路上就是完全失败的。”

在他看来，早期采用“广而浅”的策略获取用户可以理解，但长期来看，这种模式无法抵御上游模型厂商的功能下沉和垂直领域专业厂商的渗透。

大家的批评焦点高度一致，都集中在 “能否真正解决问题” 上：

1. 当用户面临真正复杂、专业的问题时，目前的通用Agent往往束手无策。
2. 当一个Agent宣称自己能处理所有事情时，通常意味着它在任何一个特定领域都无法做到顶尖。
3. ……

上述观点或许有些极端，因为通用Agent无疑代表了一个重要的技术发展方向，只是当前的发展阶段尚不成熟，表现欠佳。

其中一句批评尤为关键：“Manus仍然没有建立起有效的场景壁垒。”

它缺乏专业数据积累、没有专属的工具链、未经行业权威认证、未能与特定业务流程深度绑定集成，也没有切入高价值的核心业务场景。简而言之，它的可复制性太强，任何人都能尝试开发类似产品。 因此，它更像是对现有工程能力的延伸，而非在构建深厚的场景护城河。

“任何人都能做”意味着实现成本相对较低。但这里的“成本不高”是相对的，即便是垂直领域的Agent，也普遍面临以下挑战：

1. 精准的意图识别：用户的需求往往模糊、多变且隐含深层意图。智能体必须理解用户的“言外之意”，这对用户体验是一道高门槛。解决它需要极其精细的提示工程设计和海量的对话数据进行调优。
2. 强大的工具生态：智能体的能力边界取决于它能调用多少、多好的工具。一个Agent能否真正解决问题，要看它能否高效集成并利用各类服务（如预订、查询、控制、分析等）。自建工具链成本极高，因此与第三方服务的集成能力至关重要。
3. 深厚的领域知识：在垂直行业中，通用知识远远不够。需要将行业的SOP（标准作业程序）、私有数据库、专家经验深度注入到智能体中。这部分工作是“脏活累活”，没有捷径，却正是构建竞争壁垒的关键。

这也正是红杉资本等机构推崇 OpenEvidence 这类项目的原因：AI应用的竞争重点，正从单纯的技术能力比拼，转向产品定义、用户体验打磨、生态整合与垂直行业知识深度的竞争。早期的市场红利，将属于那些在垂直领域扎得无比深入的团队。

那么，既然通用Agent尚不成熟，为何仍能吸引如此多的关注与追捧？

追捧的背后：期待与资本的共舞

王显甚至认为，这场通用Agent的泡沫是创业公司与资本市场共同催生的产物：

“Manus根本不是在认真做产品，而是在走资本路线，通过持续制造市场声量来获取更高额度的融资。至于创始人拿到钱后，是真正深入场景打磨产品，还是另有打算，只有他们自己清楚。从产品角度看非常失败，但从营销角度可谓极其成功。”

另一位从业者张森森也表示：“国内许多Agent产品功能堆砌繁多，但大多是快速拼凑的结果，缺乏对核心痛点的聚焦。”

“例如，市面上大量集成了文案写作、PPT制作、资料查询、图片生成等功能的产品，其中不乏大厂身影。它们都具有通用Agent‘大而全’的特点，但功能多而不精。写代码准确率不高，数据分析缺乏可解释性，设计产出质量不稳定。初次体验或许觉得新奇，但难以形成长期依赖。它们很少能提供明确绑定工作流、可衡量KPI的实际交付成果。”

那么，正如各位观察者所言，既然通用Agent还不成熟，为何大家依然趋之若鹜？这里有一个真实案例：

前两个月，我的一位好友（某公司高管）所在团队开发了一款类Manus产品。他私下向我吐槽产品毫无技术壁垒、一个月就开发完成、幻觉问题严重。然而，他们公司的老板却当即决定 All In（全力投入）！

原因无他，只因马化腾为他们的产品点了赞！ 个人的看法或许不重要，资本的看法才至关重要。并且，正因为这类产品初期开发成本相对较低，创业公司更乐于投身其中。

另一方面，我组织的AI训练营中，有位学员刚获得了一亿元的融资。他们从事的是垂直领域的Agent创业。恰恰是在那个细分领域，Manus等通用产品遇到的绝大多数难题，他们也几乎全部遭遇了：

1. 产品的宣传效果与实际能力存在显著落差，并非完全无用，但差距明显。
2. 能够成功演示的，往往是任务中那20%高度标准化的部分；而真正构成工作核心的，是剩下80%充满“长尾异常”和复杂多变的现实情况。

从这些角度看，原文的剖析可谓一针见血，十分中肯。

总而言之，我从中得出的结论是：作为既得利益者，通用Agent的鼓吹者绝不会承认自身的局限。资本参与者短期内也不太关心它们是否真的‘能行’，毕竟这批人是目前最懂AI的群体，相比其他人，他们成功的概率看起来总是更高一些。

接下来，我们开始探讨Agent存在缺陷的根本原因。

深挖：Agent缺陷的根源何在？

关于这部分论述，我特别认同郭炜的观点：“许多Agent公司并未真正沉下心来深入用户场景。”

本期为大家介绍一款名为《浮生十梦》的开源项目，它是一个基于Web的、由AI驱动的动态沉浸式文字冒险游戏，并支持通过Docker进行一键式便捷部署。

文字冒险类游戏的口味比较分化，评价往往趋于两极：对其着迷的玩家会非常投入，而不感兴趣的玩家则可能完全不愿尝试。

我在实际体验一番后，感觉这款游戏相当有趣。在游玩过程中需要谨慎抉择，一不小心就可能导致“修为尽毁，神魂崩散，道消身殒”的结局。

游戏简介：在十次梦境中与命运博弈

完整的项目名称是 haorwen/TenCyclesofFate-docker，它基于原项目 CassiopeiaCode/TenCyclesofFate，两者均可在GitHub上搜索找到。

《浮生十梦》是一款基于网页的沉浸式文字冒险游戏。玩家在游戏中将扮演一个与命运进行博弈的角色，每天拥有十次机会进入不同的“梦境”（即十次生命轮回），去体验由大型语言模型动态生成的、独一无二的人生故事。游戏的核心机制在于“知足”与“贪欲”之间的抉择：玩家必须时刻权衡，是选择见好就收，稳妥地获取当前收益，还是为了追求更高的回报而冒险一搏，但同时也可能面临失去一切的风险？

核心亮点：动态AI叙事与智能反作弊

• 动态AI生成内容：每一次游戏体验的故事均由大型语言模型（例如GPT系列）实时生成，确保了每次冒险的独特性和不可预测性。
• 实时交互体验：通过WebSocket技术实现前端与后端服务器的实时通信，为玩家提供流畅且响应迅速的游戏交互过程。
• OAuth2用户认证：集成了Linux.do的OAuth2服务，为用户登录提供了既安全又便捷的解决方案。
• 精美的前端界面：采用了颇具“江南园林”风格的用户界面设计，营造出一种古风雅致的沉浸式视觉氛围。
• 互动式天命判定系统：游戏中的关键行动有机会触发“天命判定”。此时，AI会基于情境请求一次D100（百面骰）投掷，并根据“成功”、“失败”、“大成功”或“大失败”的结果来实时扭转叙事的走向，极大地增加了游戏的随机性与戏剧张力。
• 智能反作弊机制：内置了一套基于AI分析的反作弊系统。该系统会持续分析玩家的输入行为模式，旨在识别并惩罚那些试图使用“奇巧咒语”（例如Prompt注入等技巧）来破坏游戏平衡或牟取不当利益的玩家，从而有效维护了游戏环境的公平性。
• 完善的数据持久化：玩家的游戏状态会定期自动保存，并且在应用重启后能够顺利加载，保证了游戏进度不会意外丢失。

部署指南：以威联通NAS为例

这里将以威联通（QNAP）NAS作为平台，演示通过Docker Compose方式来部署此游戏。

部署所需的代码示例如下：

services:
  app:
    image: docker.cnb.cool/haorwen/tencyclesoffate:latest
    container_name: elysia-game
    ports:
      - "8573:8000" # 冒号左侧的8573可自行更换为其他未被占用的端口
    volumes:
      - /share/Container/tencyclesoffate/data:/workspace/data # 可自行更改宿主机存储路径
    restart: always
    environment:
      # 基础服务配置
      - HOST=0.0.0.0
      - PORT=8000
      - UVICORN_RELOAD=false

      # AI模型配置，兼容OpenAI API格式的皆可，需自行更改URL和模型名称
      - OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx
      - OPENAI_BASE_URL=https://api.siliconflow.cn/v1
      - OPENAI_MODEL=deepseek-ai/DeepSeek-V3.2 # 用于文本对话生成的主模型，可自选
      - OPENAI_MODEL_CHEAT_CHECK=deepseek-ai/DeepSeek-V3.2 # 用于反作弊/行为判定的模型，可自选

      # 以下功能默认关闭，个人部署可忽略
      - ENABLE_REDEMPTION=false
      - ENABLE_LINUXDO_LOGIN=false

      # OAuth相关配置，如果无需使用可全部删除
      - SECRET_KEY=Kp3s9QeF7XbL2YwH8dZ4A6CTrmN5J0uVxR1iGSkEoPByMWcUahj
      - ALGORITHM=HS256
      - ACCESS_TOKEN_EXPIRE_MINUTES=30

      # 数据库配置，采用轻量级的sqlite，个人使用无需MySQL
      - DATABASE_URL=sqlite:///./data/veloera.db

实际上，完整的部署配置需要调用额外的配置文件，但为了简化个人部署流程，上述代码已经将大部分关键环境变量直接写入docker-compose.yml文件中。如果您需要查看完整的配置选项，建议前往项目原页面进行查阅。

转眼又到了二月才迎新春的时节，公司的年会活动自然也相应推迟。提到年会，流程或许可以从简，节目表演也能随缘安排，但抽奖这个核心环节绝对不可或缺。无论公司规模大小，只要设置了抽奖，现场的热烈气氛总能被瞬间点燃。

本期将为大家介绍一款功能强大的抽奖工具，它支持Docker一键快速部署。这款工具设计简洁，无需登录任何账号，也不依赖于复杂的线上服务，真正做到开箱即用，同时凭借其出色的视觉效果将现场氛围感直接拉满。

项目概览：LOG1997/log-lottery

该项目的完整名称是 LOG1997/log-lottery，您可以在 GitHub 上搜索找到它。

log-lottery 是一个基于 Vue3 与 Three.js 技术栈构建的可配置、可定制化抽奖应用。它以炫酷的 3D 球体为核心视觉元素，专为年会抽奖等场景设计，支持对奖品、人员名单、界面风格以及背景图片音乐进行全方位配置。

重要提示：请务必使用 PC 端最新版本的 Chrome 或 Edge 浏览器以获得最佳体验。

若初次访问网站遇到图片无法加载或出现错误提示，建议您先前往【全局配置】-【界面配置】菜单，点击【重置所有数据】按钮清除缓存数据，然后刷新页面即可。

核心功能亮点

• 🕍 炫酷3D球体：年会抽奖的视觉效果担当，真正做到开箱即用。
• 💾 本地持久化存储：所有配置与数据均安全保存在本地。
• 🎁 灵活奖品奖项配置：可详细设置各奖项的名称、数量、图片等信息。
• 👱 抽奖名单管理：便捷的人员名单添加、编辑与删除功能。
• 🎼 背景音乐播放：支持自定义上传并播放背景音乐，烘托现场气氛。
• 🖼️ Excel表格支持：支持通过 Excel 表格批量导入人员名单，抽奖结果也可导出为 Excel 文件。
• 🎈 临时抽奖环节：可随时添加计划外的临时抽奖活动。
• 🧨 国际化多语言：应用界面支持多种语言切换。
• 🍃 自定义背景：允许更换整个应用的背景图片。
• 🚅 Docker 容器化：提供官方 Docker 镜像，便于快速部署与迁移。
• 😘 弹幕功能：此功能目前仍在开发中。
• 🧵 多形状卡片组合：该项功能已在规划之中。

详细部署指南：以威联通NAS为例

本文将演示如何在威联通（QNAP）NAS上，通过 Docker Compose 方式部署此抽奖应用。整个部署过程相当简便。

项目原作者提供的部署命令如下：

docker run -d --name log-lottery -p 9279:80 log1997/log-lottery:latest

我们可以将其转换为更易管理的 Docker Compose 格式：

Nextcloud 是一款功能强大的开源自托管私有云平台，其核心目标在于协助个人用户、工作团队或企业构建一套完全自主掌控的文件存储与协同工作系统。该平台不仅集成了丰富的办公应用、通信工具及安全防护功能，更被誉为“企业级 Dropbox 替代方案”，同时也是普通用户实践数据主权理念、守护个人数字资产隐私的关键工具。

多种Docker Compose部署方案

方案一：使用社区志愿者维护的镜像 此方案采用官方 Nextcloud 镜像的最新版本，适合追求原生体验的用户。

services:
  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    ports:
      - 8080:80
    volumes:
      - ./nextcloud:/var/www/html
      - ./apps:/var/www/html/custom_apps
      - ./config:/var/www/html/config
      - ./data:/var/www/html/data
    restart: unless-stopped

方案二：使用linuxserver维护的镜像 linuxserver 镜像经过优化，提供了更便捷的环境变量配置。若部署后出现 504 网关超时错误，可优先检查文件权限设置。

services:
  nextcloud:
    image: linuxserver/nextcloud:latest
    container_name: nextcloud
    ports:
      - 8080:80
      - 8443:443
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/data
      - ./config:/config
    restart: unless-stopped

方案三：集成MariaDB数据库的完整方案 对于计划长期使用的生产环境，推荐将 Nextcloud 与独立的数据库服务（如 MariaDB）搭配部署，以获得更好的性能和可靠性。

services:
  nextcloud:
    image: linuxserver/nextcloud:latest
    container_name: nextcloud
    ports:
      - 8080:80
      - 8443:443
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./data:/data
      - ./config:/config
    restart: unless-stopped

  db:
    image: linuxserver/mariadb:latest
    container_name: nextcloud_db
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=MYSQL_ROOT_PASSWORD
      - MYSQL_PASSWORD=MYSQL_PASSWORD
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
    volumes:
      - ./mariadb:/config
    ports:
      - 3306:3306
    restart: unless-stopped

关键环境变量说明：