做了 12 年漫画后，快看决定制造一种属于 AI 时代的互动内容形态。
这个项目叫做 Livo，将于近期上线应用商店。这是继条漫、漫剧、AI 陪伴互动漫画之后，快看在内容边界上的一次大胆探索。
在试用过程中，我确实感受到了一种非常新的体验。它叙事性极强，用户的一次次选择和对话，都会改变其与角色、环境的关系。在一个个剧情完整的仿生世界里，充斥着诸多 NPC。即使用户离线，或者不与他们交流，这个仿生世界依然会自发运转、产生互动。在既定的故事主线之外，角色们甚至能发展出独立于用户的情节。
传统 RPG 游戏也有 NPC、支线和好感度系统，但这些变化基本被限制在预先写好的有限剧情树里。而 Livo 允许 Agent 根据角色过去的经历、当前的心智关系、环境的变化以及用户的行为，动态“涌现”出全新的故事和交互体验。可以说，每个用户都在经历一个独一无二的平行世界。
Livo App 体验版截图，从左到右分别是 Livo 世界版图、故事地图、主要人物对话界面、“照见”页面
为了支撑这样一个互动叙事世界，Livo 搭建了一套新型 Multi-Agent 架构。
整个系统最上层是 World Agent，负责故事整体运行，管理角色日程、事件、天气、运势等影响整体状态的因素。Soul Agent 则负责用户与角色之间的交互，下面进一步拆分出聊天、“活着”、“照见”、执笔者等不同能力。故事中的每个角色本身也是一个独立 Agent，可以拥有不同的人设、世界观和状态，并调用不同的 Sub-agent 和 MCP 服务。再往底层，还有 Memory 和因果编剧。前者需要保存和召回用户、角色、剧情长期积累的信息，后者负责维持长时间运行后的故事因果。
这些都是快看过去十几年几乎没有遇到过的技术命题。
过去十多年，快看的核心技术基建属于“搜索引擎与推荐机制”驱动的上一代互联网内容平台范式。
到了 Livo，随着 Agent 成为产品背后的驱动器，一套新的工程问题也随之出现。
系统需要接入多个 MaaS 平台。模型调用成为一笔需要精细管理的持续成本，团队需要设计检测机制，判断模型服务是否因量化等因素出现效果偏差。
为了处理复杂的长期记忆与因果逻辑，数据库选型从 MySQL、Mongo 等关系型数据库，转向 VDB（向量数据库）与 GDB（图数据库）。
数据追踪体系也发生了转移。过去的 Trace 管理依赖神策等传统的端上埋点上报，现在则需要借助 Langfuse、LangSmith 等工具记录完整的调用和决策链路。
对于部分重要节点，团队会根据线上效果和评测结果决定是否进行 Post-Training。快看漫画 Agent 研发负责人，AI 工程师杨超对 InfoQ 表示，为了达成效果、故事一致性和推理成本之间的平衡，团队会在 multi-agent 系统的具体功能节点上做 Post-Training。
打造 Livo 这样的新产品形态，也直接重塑了公司内部的工作边界与组织形态。
在 Livo 项目组，三四十个人一度直接搬进同一个大会议室，CEO 陈安妮亲自带队。在这里，团队协作彻底打破了“内容提需求、产品画原型、研发写代码”的逐级传递模式。研发面对的并不是一个已有标准答案的工程实现，而是一个谁也不知道边界在哪的“无人区”，需要和整个团队一起定义工作内容。
所以采访杨超时，我们经常会听到一些很不像传统研发工程师会讨论的问题。他会谈人物关系、故事因果，以及一个互动世界需要具备的六层人格与对应世界结构。与此同时，他和团队又必须回到具体的工程问题，如 Memory 怎么设计，Agent 怎么组织，模型怎么选，系统怎么评测，数百个节点产生的推理成本怎么控制。
为了回答这些问题，他们不断从论文、产品中寻找前沿实践，再回到自己的产品里验证。
最近，Livo 内部已经历了三个大版本迭代，产品即将面向应用商店上线。团队终于从集体办公的大会议室搬了出来，杨超笑着对我们说：“昨天刚从大会议室回到工位，去沉淀沉淀。”
同时他也强调：“现在上线的 Livo 1.0 版本，其实是我们迭代的 Beta 3.0。现阶段只是先把‘有灵魂的角色’先做出来了，也算是在我们的宏大愿景里获得了一个小小的里程碑。我们会继续迭代，做深、做长，最终走向真正活着的‘仿生世界’”。
最近，快看漫画 Agent 研发负责人、AI 工程师杨超接受了 InfoQ 的采访。
我们一起聊了 Livo 研发团队如何从前沿论文和实践中寻找 Multi-Agent、Memory 等问题的解法，又如何重新构建 Agent 时代的技术栈。也聊了内容、产品和研发如何打破原有分工，共同定义产品与技术方案，以及 AI Coding 如何进一步改变这群人制造产品的方式。
更重要的是，透过 Livo 这个切片，我们可以瞥见 Multi-Agent 技术落地的真实图景。
过去一两年，“Agent 社交”喧嚣一时却未跑通闭环，产业界的目光也多聚焦于 Coding 与办公场景的效率提升。
但互动娱乐或许是一个被低估的试炼场。长期记忆、角色一致性、社会互动、因果关系和长时间运行，这些尚未解决的问题，在这里都会直接影响产品体验。
事实上，游戏与虚拟环境一直是启发和验证 Agent 前沿能力的重要实验场。从早期强化学习在复杂博弈游戏中的决策探索，到斯坦福 AI 小镇在模拟沙盒中对多智能体记忆与社会互动的机制构建，再到 PI 创始人 Chelsea Finn 借助游戏环境对具身智能泛化能力的训练，研究者早已在虚拟世界中不断拓宽智能体的能力边界。
回望历史，推荐算法最初也只是一种底层技术，后来围绕它长出了信息流和短视频。Multi-Agent 今天同样首先是一种技术，它最终会长出什么样的产品形态？我们可能才刚刚开始看到答案。
以下是 InfoQ 与快看漫画的访谈
InfoQ：你是什么时候加入快看的？这些年主要经历了哪些技术方向的变化？
杨超：我 2019 年加入快看漫画，这是我的第二家公司，到现在已经七年多了。
刚加入的时候，推荐是非常热门的方向，Transformer、深度学习这些技术也在快速发展。我当时主要做推荐相关的工作，包括漫画社区等业务的推荐。
这两年随着 AI 兴起，我开始转向 Livo 相关的 Agent 研发。现在除了 Agent 应用和系统架构，也开始参与一些 Post-Training 相关的工作。
所以我自己在快看的经历，其实也刚好经历了从推荐算法，到现在 Agent 研发的变化。
一套为互动叙事长出来的 Multi-Agent 架构
InfoQ：Livo 的 Multi-Agent 架构让我想到斯坦福 AI 小镇。你们是否参考过这类研究？Livo 的架构是怎么一步步演变出来的？
杨超：斯坦福 AI 小镇确实是我们曾经调研、参考过的一个项目。我们最开始的愿景，是打造一个像《西部世界》这样的开放式世界，所以发现斯坦福 AI 小镇之后，也会去借鉴它的一些思路，比如怎么营造角色 Agent 之间的关系、情感和人格，让这些角色彼此独立。
但斯坦福 AI 小镇更多还是科研性质的项目，我们参考这些项目，主要还是借鉴其中的想法，而不是直接照搬。
后面我们又调研了很多论文和项目。比如今年年初比较火的 LPM 模型，它给我们的一个启发是，长叙事中怎么保证因果关系。Livo 本身也是一个长程的系统，所以 LPM 出来以后，我们内部做过很多线下讨论，讨论怎么保证长程任务和叙事的持续性。
Memory 也是一个非常重要的问题。我们围绕记忆调研了数十篇论文，从叙事框架、长程任务保持，到人格和世界观怎么确定，都看了很多不同的研究。
但最后我们不会照搬其中任何一套方案。因为如果只是把现有方案拼在一起，就和公司的愿景相悖了。我们更多是从不同项目和论文里吸收经验，再根据自己的目标去设计 Livo。
InfoQ：具体来看，Livo 的 Multi-Agent 架构的组成部分有哪些？
杨超：Livo 本质上是一套 Multi-Agent 协同架构。
每个仿生世界都是一个独立运行的 World Agent。（注：打开 Livo App，你会看到多个“世界”，每个世界对应一个故事剧情。）它会管理日程、事件、天气、运势等影响整体状态的因素，下面再由不同的 Sub-agent 承担具体工作。
比如我们有天气相关的 Agent。一个故事里，大家原本按照日程在操场活动，但天气突然变成下雨，所有角色接下来的行为就可能随之变化。我们还有一个运势 Agent，会结合角色的星座、生辰等设定，为当天的行为加入一定的不确定性和戏剧性。
另一类比较大的 Agent 是 Soul Agent。它主要处理用户与角色交互相关的能力，下面会有聊天、“活着”、“照见”、执笔者等不同的 Sub-agent，支撑角色交互的不同部分。
除此之外，还有 MCP 为上层 Agent 提供更原子化的工具和数据能力。
再往底层，还有两个我们非常重视的部分：Memory 和因果编剧。Memory 负责长期连贯性，因果编剧则希望让角色的经历不是流水账，而是形成长期因果。前面发生的一件事，可能埋下一颗种子，经过一段时间后，在某次日程或对话里产生新的结果。
用户对角色的认知、角色对用户的认知，以及用户自身的画像，也都会进入 Memory 和因果关系的处理中。
InfoQ：每个角色本身也是一个独立 Agent 吗？
杨超：是，每个角色都是一个独立 Agent，由大语言模型驱动。不同角色会有不同的人设、世界观和能力，下面还可以调用不同的 Sub-agent 或 MCP 服务。
一个 Livo 故事里可能有几个核心角色，再加上二十多个 NPC，所以单是角色 Agent 就可能有二十多个。整个系统再叠加 World Agent、Soul Agent 及其下属节点，规模会更大。
InfoQ：运势 Agent 是一个很特别的设计。要为虚拟世界编排随机且合理的戏剧冲突，需要一套底层规则。而星盘、八字等概念，恰好提供了一套大众熟知，并且可以被程序化的规则体系。为什么会想到用这种方式给系统加入随机性？
杨超：这个想法来自安妮。她一开始提到“大运流年”，但我们觉得这个概念比较深，不一定所有人都容易理解，所以现阶段会用星座、生辰、MBTI 等更大众化的方式表达。
我们把这个 Agent 定义成 X Agent，本质上就是希望在整个系统运行里加入一些不确定因素和戏剧性。
安妮本身也是内容创作者出身，她的一些想法会比较跳跃。创作者在创作作品时，本来就希望塑造一个“活着”的角色或者故事。到了产品里，我们要做的，就是找到具体的产品机制和技术机制，把这种感觉实现出来。
InfoQ：Livo 没有一个成熟行业方案可以直接参考。这套架构具体经历了怎样的迭代？
杨超：Livo 现在发布的虽然是 1.0，但内部其实已经到了 Beta 3.0，经历了三个非常大的版本迭代。
最开始，我们的定义其实很简单，就是先把角色塑造好，让角色和用户聊天。但做了一段时间之后，我们发现，这并不能很好地体现角色“活着”。后来我们加入了更大的运行环境。但一开始，我们仍然把它定义成一个附属性的东西。这样做下来，又发现产品本质上还是一个聊天产品。所以再往后，我们开始真正把整体运行放到核心位置。
架构也从最开始比较单一的 Soul Agent，逐渐增加了 World Agent。World Agent 下面再增加 Director、编剧 Agent、角色 Agent、因果、天气等很多小的 Agent。
但到了这个阶段，我们又发现，只是让角色按照规则在里面行动，好像还是不够有趣。
角色需要有自己的生活，也需要有自己的因果。其实人也是一样。外界看起来，你每天可能只是上下班，好像每天都差不多。但实际上，你在这个过程中会有很多心路历程。比如周末发生了一件让你非常开心的事，到了周一上班，你可能还是哼着歌去的。
所以到了后面的阶段，我们又逐渐加入 Memory 和长程因果编剧相关的 Agent。
整个架构就是这样一点点迭代到现在。现在上线的 Livo 1.0 版本，其实是我们迭代的 Beta 3.0。现阶段是先把“有灵魂的角色”先做出来了，也算是在我们的宏大愿景里获得了一个小小的里程碑。我们会继续迭代，做深、做长，最终走向真正活着的“仿生世界”。
记忆是一个推荐系统
InfoQ：在记忆设计上，你们受到过哪些研究或者产品的启发？
杨超：记忆这块我们做了很多调研。比如印度有一家叫 Pocket FM 的公司，它比较强调叙事关系。还有一些产品会强调长期的情感关系。
我们特别赞同一个观点：记忆是一个推荐系统。
记忆不应该只局限于“以前发生过什么，我把它记住”。这种最基本的记忆，更像 B 端产品里的需求。比如一个 Workflow，第一步、第二步做过什么，系统一定要记住，才能顺利执行第三步。
但 C 端产品是直接面对用户的，用户需要长期在里面体验。所以我觉得只是“记住”肯定不够。
我们现在把记忆系统大致分成三个阶段。
第一阶段，让系统知道什么时候应该想起什么，进行角色建模，用户建模，剧情建模，和心智模型的训练。
这个过程有一点类似大模型里的 MoE 激活机制。
比如一个 MoE 模型可能定义了很多专家，但这些专家不会在每一次请求中全部被激活。如果你问的是一个法律问题，它会激活最适合处理法律问题的专家。这样可以在只激活一部分参数的情况下，仍然保持很强的整体能力。
第二阶段，让系统利用记忆重建当前状态、理解用户和角色、推理因果、模拟不同未来，并选择下一步行动。
第三阶段，让系统从所有用户的预测与真实结果之间持续学习，把个体经验沉淀成能够跨用户复用的记忆策略、用户先验、剧情策略和因果模型。
InfoQ：Livo 有大量 Agent、状态和行动。长期记忆怎么避免不断膨胀，最终失效？
杨超：记忆有很多不同实现方式。比较基础的方案，可以像一些 Coding Agent 那样，把长期信息记录在 MEMORY.md 一类 Markdown 文件里。但文件本身有上下文长度等限制。
更长程的记忆通常会引入向量数据库，将记忆向量化（embedding）后存储，再根据当前查询（query）进行检索和召回。
Livo 首先会用 VDB（vector database，向量数据库） 存储基础记忆。用户和角色之间发生过的聊天、日程、命运相关事件等，都会抽取事实后进入记忆。
在此之上，长程因果会使用 GDB（graph database，图数据库） 来表达。重要事实可以成为图里的节点，节点之间则定义不同类型的边。比如前面埋下的伏笔后来被回收，可以形成"呼应"关系；一个事件导致另一个事件，可以形成"因果"关系；比较弱的长期关联，则可以定义成"回响"等。
同时，我们不会让记忆无限线性追加。系统会持续对角色、剧情、用户等维度进行总结和更新。底层向量记忆还会设置重要性和遗忘机制。如果一段记忆随着后续发展已经不再重要，就可以逐渐降低权重或遗忘。
我们也会设计类似 LRU/LFU 这样的保底机制，保证真正重要的信息被留下来。
如何为 Livo 做 Post-Training？
InfoQ：为什么 Livo 会考虑对 Multi-Agent 系统中的部分节点做 Post-Training？
杨超：一方面是成本。如果 Livo 的用户量达到一定规模，Token API 成本会非常高。现阶段这个成本本身就比较贵。
另一方面是效果。通用模型的一些能力，并不足以支撑 Livo 后面对于强故事性、强人格一致性的要求。
我们有一个比较宏大的愿景，是做“AI 时代的迪士尼”。从技术上，我们也想打造自己的模型能力。
不管是从技术壁垒角度，还是从实现产品目标的角度，我觉得在一些关键节点上做 Post-Training 都是有必要的。
整个 Multi-Agent 系统里大概有 200 多个节点。不同节点的重要程度不一样。对于一些直接影响用户体验的重要节点，我们会探索通过 Post-Training 保证效果。
InfoQ：能不能举一个具体的例子？
杨超：比如刚才说到的心智模型。
我们希望对用户、角色和剧本做建模。我们的目标不只是传统意义上的“记住”，而是进一步探索用户的心智。也就是说，不只是拿到用户以前说过什么，还希望通过很多不同维度理解用户当前场景下的状态，并对下一步做一定的推测。
具体来说，它可能不是传统意义上的意图分类，而是有 128 个以上的特征维度，再从中输出当前需要激活的 32 个维度。
在这个节点的 Post-Training 上，我们会先从 SFT 入手，先固化它应该具备的一些能力，让输出符合正样本分布。
但这 128 个维度本身不是固定不变的。不是永远只有姓名、年龄、偏好这些静态信息，它们会不断变化。所以后面我们还可能增加 DPO、GRPO 等方法，进一步支持这种变化和泛化。
Multi-Agent 系统如何建立评测闭环？
InfoQ：怎么判断一个节点什么时候需要进入下一阶段的 Post-Training？
杨超：做 Agent 应用肯定不能盲飞，也不能靠猜。我们组内有很多基础设施项目，比如 Eval 测评平台。
做 Post-Training 之前一定要拿到基座模型的 Baseline。
比如基座模型在 Eval 的指标评测下是 60%，那 SFT 阶段我们可能希望把它提高到 80%，远期目标可能是 98%。如果到了 80% 之后，我们发现当前方法已经到达瓶颈，但距离最终目标还有差距，这时候才会考虑引入后续阶段。
所以它必须是基于评测结果来决定的。
InfoQ：你们内部也会有自己的 Benchmark？
杨超：对。比如 Memory，我们会跑一些现有的公开 Benchmark，也会定义很多业务自己的评测维度。只有这些评测维度都达到要求，我们才会认为当前优化到了可以上线的程度。
从一开始的 Prompt 编写，到 Post-Training，再到其他优化，它一定要形成一个数据飞轮。不能只是人工试几次，觉得“挺不错，可以上线”。因为那可能只对你有效，80% 的用户体验并不好。
所以一定要有质量管控。
InfoQ：上线以后，怎么继续评测和迭代？
杨超：上线以后，我们预计会抽样用户真实的线上数据，再反馈到业务平台。如果线上指标不满足预期，可能通过一些自动化方式继续优化 Prompt、模型或者相关节点，然后重新推到线上验证。
AI 时代很重要的一点，是每一次模型调用、每一次模型决策都会有自己的 Trace。
这些 Trace 我们都会采集。比如整个系统有 200 多个节点，这一次我们只关注心智模型的效果，就可以把这个节点单独的输入和输出采样出来，形成一个评测集，再做一轮线上回归评测。
整个评测飞轮大概有两条链路。
第一条是自动感知线上用户行为，通过真实 Trace 持续做迭代优化。
第二条是 Bad Case。比如用户觉得某一条内容不好，可以直接点踩。我们会把这条数据标记成 Bad Case，单独收集起来，针对性地优化和调整。
评测体系里还会有很多不同类型的评测集，包括线上抽样形成的评测集、对抗集、Bad Case 集等。这些评测分别达标之后，才可以继续线上放量。
所有 AI 产品都一定要评测先行，Post-Training 也是一样。没有先达到一个明确的基准指标，就去做后续事情，最后很容易变成主观判断。
如何兼顾故事线统一和模型涌现能力？
InfoQ：Livo 一方面希望保持故事线统一，另一方面又希望利用模型的涌现能力。两者怎么平衡？
杨超：我们有一个 Agent 叫执笔者 Agent。如果通俗一点理解，可以把它想成“老天爷”。
创作者首先会保证整体故事是有序的，会定义一些“注定的命运”，包括关键剧情钩子、剧情内核、目标方向和结束条件。在这些创作者明确控制的内容之外，执笔者 Agent 负责补足中间的连续性，让故事能够持续往前走。
我们把相关情境分成几类。第一类是“注定的命运”，对内容精度要求很高，主要由创作者控制。除此之外还有“潜在的命运”，内部又分成红情境和黑情境。红情境允许执笔者 Agent 在已有内容上做一定改写，黑情境则可以由执笔者 Agent 更充分地生成。
比如上一段剧情发生在车站休息室，下一段已经确定的剧情是在火车餐厅喝咖啡。中间跨度很大，执笔者就需要生成一些过渡情境，让人物合理地抵达下一个节点，而不是突然跳过去。
InfoQ：“活着”和“照见”这两个能力分别是什么意思？它们是单独的 Agent 能力吗？
杨超：我们内部把“活着”拆分为 3 个方面。
一是主体性。角色为自己而存在，会拒绝，会有情绪。他有自己的小执着、小习惯、小秘密，有跟人相处的周期变化，比如疲惫、欢喜、冷战。
二是成长变化的演进。角色会因为和你相处真的发生改变,而且不可逆。你可以改变一个人。
三是环境场域里的实践活动，也就是世界地图模块的价值。角色不可能在真空里活着。你不打开 App 的时候他也在这个地方生活，会在某个时刻"想起"你。
这里需要强调，“想起”是叙事性的，会体现在情节中，不是 Livo App 给你 push 通知。我们用双时钟实现这一点。一个低频的合理性时钟在后台推进世界状态,保证情节通顺合理，还有一个戏剧性时钟像导演一样挑出高张力时刻,决定什么时候讲给用户听。
“照见”更多和心智模型有关，是有层次的。
首先是被读懂。比如你说了一句别人可能听不懂的话，但他知道你的言下之意；或者你有一个自己都没太意识到的小执着，他没有否定你，只是记住了、看着你。
再深一点，是接纳和成长。因为长期被这样看见，你可能会更理解自己，也更能接纳自己不那么完美的部分。我们希望用户和一个角色相处足够久之后，最后看到的不只是这个角色发生了什么变化，也会慢慢看到自己是什么样的人，或者自己想成为一个什么样的人。
它们都不是单独的 Agent 能力。 "活着"由灵魂引擎、世界引擎、双时钟、创作者 Harness 共同兑现;"照见"由深度感受、记忆系统、用户侧演化共同兑现。
这些都是整体产品体验共同产生的结果，这个共同结果也是需要用户加入共创涌现出来的，这也恰恰是 AI 时代应用产品最大的魅力所在。
Agent 时代，快看如何更新技术栈？
InfoQ：过去快看作为内容平台，核心技术问题更多围绕内容生产、存储、推荐和分发。到了 Livo 这样的 Multi-Agent 产品，技术栈发生了哪些比较大的变化？
杨超：快看过去主要做内容创作和分发时，面对的是比较典型的互联网时代问题。
那个阶段，存储首先要保证稳定和高并发，效率是很重要的目标。所以 Infra 更关注结构化、半结构化或者非结构化数据的存储。比如 MySQL、MongoDB、Redis，以及 Kafka 这样的消息队列。核心是让内容安全地存下来，需要查询时又可以快速分发给用户。
到了 AI 时代，尤其是 Livo 这类产品，整体技术栈和 Infra 会发生比较大的变化。
首先是 MaaS 平台。我们需要接入不同模型 API，这在过去的技术栈里基本没有。
选择 MaaS 平台时还有一个问题，就是你需要判断供应商实际提供的模型服务质量。我们实现了一些类似 LLMmap 这样的指纹识别的方案。我们可以拿官方渠道的模型流量作为基准，再训练一个识别网络，定时或者定点检测一些可能有问题的流量。
第二个变化是数据。过去更多是端上埋点，把数据上报到数仓里存储。到了 AI 产品里，我们还需要维护大量 Trace，而且这些 Trace 的信息量会非常大，所以需要引入新的技术方案。
数据库层面的选型也会随之变化。MySQL、MongoDB 等原有数据库仍然会继续承担需要固化存储的内容，但在它们之外，我们会增加 VDB、GDB 等新的数据库能力。尤其在多模态场景下，还需要考虑视频、音频等数据怎么进入检索体系。可以直接围绕多模态数据建立检索，也可以先通过 OCR 等方式转成文字再存储。多模态数据本身会给查询增加新的信息维度。
Trace 管理上，过去更多通过神策、观远这类工具做端上埋点和用户行为分析。到了 AI 时代，我们还需要 Langfuse、LangSmith 这类工具，对模型和 Agent 的调用链路进行 Trace 和可观测。
第三个变化是应用框架。过去做内容分发，可能更关注 Spring、Java 等传统工程技术栈。做 Multi-Agent 之后，会更多关注 LangChain、LangGraph 这类 Agent 应用框架。
Multi-Agent 如何系统性降本？
InfoQ：Livo 有大量 Agent 和模型调用需求。整体成本主要来自哪里，又怎么优化？
杨超：成本主要有两个来源，一个是推理，一个是基础存储。其中推理肯定是大头，因为系统里的节点和 Agent 非常多。
我们做成本优化会考虑几个方面。
首先是业务约束。哪些节点、哪些流程可以精简，能不能减少一些不必要的调用。
第二是推理本身。比如 Prompt 怎么设计才能提高 KV Cache 命中率，Input Token 和 Output Token 也都需要控制。
第三是 MaaS 平台选型。不同 MaaS 平台提供的模型服务在量化方式、稳定性和实际效果上可能存在差异，所以我们会选择更加稳定、可靠的合作方。
再往后，如果用户规模达到一定程度，我们也可能通过 Post-Training，用模型训练和推理的机器成本去替代一部分长期的 Token API 成本。
在内容公司做研发，是怎样的体验？
InfoQ：在一家内容公司做 AI 技术，研发和内容的关系似乎会比传统软件公司更紧密。例如一些 AI 漫剧公司，技术是非常紧密地和内容、产品一起，定义生产流水线的。不知道你有没有这样的感受？
杨超：Livo 不是按部门拆开做的，整个项目组就在一个大办公室工作。很多方案来自集体脑暴。每个人提出自己的想法，也提出不认可的地方，形成一个阶段性方案后，再去调研会上提到的论文和项目，最后回来确定当前架构。
我们内部把这种方式称为“群体人工智能”。这里的"群体"首先指的是人。大家共同讨论，再借助外部研究和 AI 工具，把想法逐渐收敛成产品和技术方案。
但是我们和 AI 漫剧公司，或者 Liblib 这样的公司还是不一样的。他们的内容生产平台往往会重点打磨一条比较明确的 Pipeline 或 Workflow。比如先理解剧本，再做分镜，每一个节点都有比较明确的质量要求，也可能通过多轮 ReAct 等方式保证节点执行效果。
Livo 不太一样。我们希望在可控的边界里释放大模型的创造力和涌现能力，所以不会把 Pipeline 或 Workflow 定得特别死。研发、产品、内容、设计需要一起不断打磨对产品的理解，再决定哪些部分应该约束，哪些部分应该留出灵活性。
InfoQ：内容创作侧有哪些专门为 Livo 搭建的工具？
杨超：我们内部有一个面向创作者的平台，叫 Magic。它主要有两类能力。
一类是辅助创作者生成图片、视频等多模态素材。另一类是我们为 Livo 设计的 Creator Harness。
我们不希望强行改变创作者原有的创作习惯。创作者可以继续用小说、剧本、分镜等自己熟悉的形式表达故事，系统再把这些内容抽象、建模成 Livo 所需要的结构。
Creator Harness 里，我们会把角色人格拆成六层：意识、需求、信念、思考方式、状态和情绪。
前四层比较底层，不太容易改变，相当于角色最核心的人设。后面两层，也就是状态和情绪，会随着每一次互动和对话不断变化。比如角色现在是高兴还是生气，这是情绪。腿折了还是健康地跑，这是状态。
创作者提供原始文学内容之后，我们会把它抽象、建模成这六层人格，再把这些内容真正注入角色 Agent 的上下文。
这六层是产品和内容一起敲定的。
快看漫画的 AI Coding 实践
InfoQ：快看是什么时候开始出现 Agent 研发这类岗位的？
杨超：整个行业都是最近两年才出现这类岗位。
我个人的感受是，Manus 出现以后，行业对“Agent 应该是什么”有了更直观的认识。以前大家也在做很多 AI 应用，但 Manus 展示了一种比较完整的端到端工作方式：用户给出一句话，系统可以制定计划、调用工具、处理 Excel 等任务，最后交付完整结果。它让更多人理解了 Agent 的产品和工程形态。
这里更多是我个人对行业变化的判断，不是说此前行业完全没有 Agent 研究或相关岗位。
InfoQ：在 Livo 之前，快看内部已经开始使用 AI Coding 了吗？
杨超：是。2023、2024 年左右，我们就开始在代码补全等场景使用 AI。最早是 GitHub Copilot 这类工具，在 IDE、PyCharm、VS Code 里通过补全提高效率。
后来 Cursor、Claude Code、Codex 等 Agentic Coding 工具出现以后，AI Coding 从“点”扩展到了“面”。过去工程师更多是一行一行实现，现在人需要把握整体方向和架构，让 Agent 帮你完成更大范围的实现，也就是“人类掌舵，智能体执行”。
这其实提高了对工程师整体能力的要求。如果你自己不能把握架构，只是让 AI 零散地写，很容易最后变成只有 AI 能看懂、人工很难维护的代码。
公司对具体工具没有特别强的统一限制，大家可以根据自己的习惯选择。
InfoQ：个人用 AI Coding 和大型团队共同维护一个代码库完全不同。你们怎么避免多人协作最后变成“AI 屎山”？
杨超：这也是我们在 Agentic Coding 出现后逐渐摸索出来的一套 AI Coding SOP。
最开始，各团队会分块做自己的提效，比如 iOS、服务端、推荐分别定义自己的 Skills 和约束。但后来我们发现，各组之间仍然存在上下文沟通壁垒。
所以后面开始引入一个更整体的 Orchestrator 做编排，同时维护统一的 AI Docs / Specs。
这些文档包括契约类文档、设计文档、PRD，以及 DEV Context，也就是研发过程中做过的重要决策。新的研发同学进入项目后，可以通过这些文档快速获得统一上下文，也避免过去踩过的坑被重复踩一遍。
不管工程师具体使用哪一种 AI Coding 工具，这些文档都需要作为上下文加载进去。某种程度上，它们就像整个项目共享的 system prompt。
InfoQ：Spec 本身也会不断变化。怎么避免每个人都随意修改，最后失去约束力？
杨超：架构性质的文档不能随便改。涉及架构和关键规范的内容，需要团队先讨论、对齐，形成共识，再由相关领域比较资深的人 Review，最后才能进入正式 Spec。
这些文档可以由人和 AI 一起创作，但最终必须由人审核。特别是基础架构和关键决策，不能把 Review 完全交给 AI。
AI 更像是在放大人的能力，而不是让一个人从零开始就自动拥有原本不具备的工程能力。从 Copilot 到 Agentic Coding，工具能处理的范围越来越大，对人的整体判断能力要求反而更高。
