KCD 议题可视化实践：用 AI Agent 为开源社区赋能
这个仓库是我在 KCD 2026 北京会场与 Keith 讨论后，给出的个人答案。
一切的思考始于一个问题：我们如何利用 AI Agent 来赋能开源社区？
其中一个方向是“为 PPT 打点”，这个 repo 便是该实验的成果。
感谢 Keith 和晋涛的授权，让我（Cloud Native 分会场的控场人）能够访问大家的 PPT 来完成这个实验。由于未获得公开授权，这里就不放出 PPT 源文件了。
在这个项目中，我不仅完成了可视化的实验，还实践了 Harness 的理念。代码均由 DeepSeek 生成，我未动笔，欢迎大家随意修改和提交 PR。
理论上，数据可以换成任何一场 KCD 或 KubeCon 的议题。
在接下来的步骤中，我将逐一解释每个环节的为什么、硬性约束与软性约束是什么，并在可能的地方，对应“古法编程”时代的经典概念。
正如我在 KCD 晚宴中与嘉宾和社区爱好者分享的：如果可以，请不手动编写代码。我们的角色是设计环境、明确意图、构建反馈回路，并借助可观测性来指导 AI 进行调试。
以下是本项目遵循的核心设计原则：
1. 最小可控
类似 Autoresearch 的设计，遵循“最小可控”原则，仅对必要环节施加控制。
2. 硬约束与软约束的平衡
实验受两类规则支配：硬约束由系统架构强制执行，软约束则指导代理的决策。理解这些规则，是解释实验结果和把握修改边界的关键。
3. 测试驱动开发
先明确最终结果，再反向设计硬约束与软约束。
4. 可观测性——以日志为主
本项目规模较小，日志足以支撑观测与调试需求。
5. 封底估算——控制成本
KCD 为一天，KubeCon 为三天。以 KubeCon 为例，上午 Keynote 后从 11 点开始，下午 1:30 开始，每个会场约 11 个议题/天，4 个会场则约 44 个议题/天，三天共计 120 余个议题。
由于本次实验的 token 由个人承担（社区的 token 多由企业捐赠，需珍惜），因此能省则省，好钢用在刀刃上。极端情况下，通过复制粘贴提示词也能在浏览器中完成分析。本项目采取类似“面向浏览器编程”的方式，旨在理解 Harness 的原理，而非完全自动化地消耗 token，最终成本仅为 0.9 元，将 token 主要用在了 PPT 内容分析上。
6. 不要提前干预
你将在后文看到标有 备注 字样的部分，其中包含一个“好的没有提前干预的例子”和一个“坏的提前干预的伏笔”，用以说明这一原则的重要性。
约束的来源——非功能性需求，成本控制
作为一个用爱发电的项目，虽然我们可以把 PPT 直接扔给模型去做分析，但那样的做法会成为 token burner。从成本控制的角度出发，首先我们对源文件进行处理，转换成文本模式。
硬约束
- 将下载好的会场 PPT 统一放入一个目录。
- 使用 Python 脚本完成转换。
- 读取目录中的 PPT 或 PPTX 文件，将其转存为 Markdown 格式。
软约束——实际上并不那么介意或追求完美，在提示词中没有加以控制
由大模型生成的脚本执行后，存在一些不完美之处：基于 pptx Python 库转录后，脚本还额外将图片单独提取了出来（虽然从成本角度我们并未要求处理或不处理图片）。另外，输出中出现了大量不必要的回车。不过，相较于一张图片所消耗的 token，这些回车带来的成本仍在可接受范围内。
验证方式：生成 Markdown 格式文件即可。
结果：ppt2md.py
约束的来源——功能性需求，可视化
思路与结果
说到数据可视化，我们要如何展现一个会场下的十几个议题？天然的，CNCF Landscape 给我们提供了技术栈的维度。大家举办 KCD 这样的峰会，目的之一是为了让听众（包括视频听众）可以快速了解演讲涉及哪些技术领域，以及具体用到了哪些项目。
通过 DeepSeek 讨论，决定将议题在 Landscape 中进行定位。
其次，为了让这些分享能够更好地帮助听众解决问题，还需评估演讲中是否存在具体案例、技术深度如何（是否易于理解）、面向的听众人群、复杂程度等。
大致思路有了，开始加入约束。首先，分析 Markdown 的提示词框架如下：
你是一位资深云原生技术专家。
我需要你帮我就以下演讲内容和 CNCF landscape 中 ${category} 部分进行对比。
给出判断：
1. 这个演讲主题是否与 ${category} 有关？
1.1 如果有关，请给出演讲内容与 ${category} 的关联。
1.2 如果有关，演讲中是否涉及具体案例？
1.3 如果有关，这个演讲的技术深度如何？听众是否需要具备前置技术背景才能听懂？
1.4 如果有关，这个演讲面向的主要听众人群包含哪些？
1.5 如果有关，这个演讲内容的技术复杂度或场景复杂度有多大？是否易于实践？
2. 议题提到了哪些具体的 CNCF 项目？
2.1 如果有两个及以上项目，在演讲中这些项目之间的关系是什么？
以下是演讲内容的 PPT：
${ppt_markdown_content}
以下是 ${category} 的介绍：
${category_introduce}
注意，第一版的提示词并未强制要求结构化输出。分析思路的最终版本是强制性约束，目前尚未确定是否采用 JSON 结构化输出。
验证方式：手动将一两个 session 的内容填入提示词框架，运行后检查相关性判断是否准确。
备注：我不想过早确认中间数据格式。我们不妨将 DeepSeek 处理的结果直接放在 Landscape 框架里可视化，从而省去维护可视化脚手架的工作。虽然思维惯性上会倾向于结构化输出、构建中间格式的接口，但我们要践行 Harness 的理念，避免过早介入。
约束的来源——功能性需求，工具限制
硬约束
landscape2 new --output-dir .
landscape2 build --data-file result.yml --settings-file settings.yml --guide-file guide.yml --logos-path ./hosted_logos --output-dir build
作为验证，将 Landscape 中的现有 logo 复制过来，确保能正常运行即可。
软约束
无
验证方式：本地启动项目通过。
约束的来源——传统意义上，这部分工作由业务分析人员/产品经理完成。
硬约束
- 理解 Landscape 的数据格式，明确哪些字段可以修改，以及修改后会产生哪些影响。
1.1 明确 Landscape 的自定义标签如何添加。
1.2 明确数据的展示方式。 - 避免本地 Landscape 环境出现问题。
软约束
无
结果
guide.yml、prepare.yml、settings.yml 等配置文件。当然，merge.py 也属于这一环节。
备注
此处我自作聪明地生成了 template.yml，为后文埋下了伏笔。
大家可以在 agentprocess.py 中找到提示词，作为步骤二的最终版本，以及数据格式。
约束的来源——提示词内容来自步骤二，数据关系和磁盘上存放的结构来自步骤四
硬约束
- 从 Markdown 文件中读取内容。
- 从
prepare.yml中获取项目列表及各类别的描述信息。 - 替换模板提示词。
- 调用大模型处理提示词。
- 将结果保存至文件。
软约束
模型可能会产生一些幻觉，例如某些具体特性（如 DRA）实际上并未出现在 Landscape 中等，这些受客观条件限制的情况属于软约束。
结果
analysis_results.json
约束的来源——数据关系和磁盘上存放的结构来自步骤四、步骤五
硬约束
- 从
analysis_results.json读取分析结果。 - 从 Landscape 的 YAML 文件中找到该 session 对应项目的原始数据。
- 进行展示用的数据替换。
- 追加写入
template.yml，生成result.yml。
软约束
项目在 Landscape 展示的原始内容。
备注——借助可观测性进行调试
大模型总是将 template.yml 与原始数据源混淆，把简单的追加覆盖变成了复制后更新，导致页面展示时议题与项目混淆。我们通过让模型增加可观测性日志，最终发现了这一问题。
结果
result.yml
人无法直接与大模型权重对话，我们需要一个 Agent。至此，我们讨论了：
- 人在可视化任务中的角色：设计环境、明确意图、构建反馈回路。
- Agent + 大模型：负责尝试与实现细节。
- 产出稳定结果的工具：帮助我们节约 token，提供稳定性约束。
- 可观测性：在 Agent + 大模型跑偏时，提供讨论依据。
接下来，我们讨论部署上线。
硬约束
- GitHub：提供免费的域名与 Pages 服务。
- Landscape：可部署在 GitHub Pages 上。
- GitHub Action：实现自动化。
软约束
无
结果
https://samyuan1990.github.io/KCDTopicVisualization/
回到最初的问题：我们如何利用 AI Agent 来赋能开源社区？
通过这个项目，我尝试给出了一种答案：让 Agent 承担繁琐的“翻译”与“打标”工作，将分散的 PPT 议题与结构化的 CNCF Landscape 关联起来。人则聚焦于设计原则、定义约束、构建反馈回路，并在关键节点借助可观测性进行干预。
整个过程并非追求全自动化，而是追求可控、低成本、可复用的自动化。希望这个实验能为大家在各自的开源社区实践中，提供一些关于“如何与 AI 协作”的灵感。