开源贡献 README
这份 README 记录我在 GitHub 上公开、可核验的开源工作。它不是一份只展示仓库数量的列表，而是把贡献拆成三类：我持续维护的公开项目、已经被上游合并的贡献，以及仍在社区评审中的改动。
文中的统计截至 2026 年 7 月 18 日。PR 状态会继续变化，判断某项贡献是否已经进入上游时，应以链接中的 GitHub 实时状态为准。
贡献概览
过去一年，GitHub 公开贡献记录包括：
| 指标 | 数量 | 口径 |
|---|---|---|
| 公开 Commit 贡献 | 266 | GitHub Contribution Collection 中可公开归属的提交 |
| Pull Request | 30 | 6 个已合并、18 个评审中、6 个关闭未合并 |
| Issue | 8 | 2 个已关闭、6 个仍开放 |
| 参与的外部仓库 | 10 | 包括代码、PR、Issue 等可归属贡献 |
| 私有贡献 | 123 | 仅作工作量背景，不计入下文开源成果 |
我的账号下还有 9 个用于阅读源码、复现问题和提交补丁的 Fork。Fork 本身不是贡献，因此本文不会把创建 Fork 计入成果；只有对应的 Issue、PR 或被上游接收的 Commit 才会列入贡献记录。
我维护的公开项目
AfterSaleFlow-Agent
AfterSaleFlow-Agent 是一个面向履约争端的 AI Native 审理协作系统。它把 Agent Runtime Harness、Temporal 长流程、人工审核和确定性工具执行组织在一起，目标不是让模型直接执行高风险动作，而是建立一条可追溯、可审批、可恢复的业务链路。
项目覆盖 Java API、Python Agent、OCR 解析、Temporal、PostgreSQL、Redis、Elasticsearch、MinIO、Langfuse 与 LiteLLM。它集中体现了我对 Agent 生产化边界的理解：模型负责分析和形成建议，业务事实、审批责任与最终执行必须由确定性系统承接。
shortlink
shortlink 从传统短链接服务扩展为智能投放与安全风控平台。基础链路覆盖短链创建、跳转、分组、统计、缓存、分片和网关治理；Agent 服务进一步承担投放分析、安全风控、风险画像和策略发布。
这个项目用于验证 Java 17、Spring Boot、Spring Cloud、Redis、ShardingSphere 与 Spring AI Alibaba Graph 如何进入同一条真实业务链路，也用于实践 Checkpoint、工具调用、内部鉴权、Trace 和策略热路径拦截。
AI Coding 工具与知识沉淀
- universal-prompt-optimizer-skill：一个零配置 Prompt 优化 Skill，通过澄清问题和结构化重写，把模糊指令变成可执行任务。
- agent-usage-guide：围绕 Harness、上下文管理和 Agent 使用方法沉淀的实践指南。
- Prompt-Collection：学习与工作过程中可复用的提示词集合。
- Notes：技术学习笔记、源码阅读记录和工程思考。
这些仓库与两个大型项目形成互补：项目验证系统能力，工具降低协作成本，笔记保存可复用的判断依据。
已合并的上游贡献
下面 6 个 PR 已经被上游仓库合并，可以视为已经进入社区版本历史的贡献。
| 日期 | 上游项目 | 贡献 | 解决的问题 |
|---|---|---|---|
| 2026-06-28 | Spring AI Alibaba | #4755 | 补充 DashScope 多模态示例缺失的 multi-model 配置说明 |
| 2026-06-30 | Spring AI Extensions | #269 | 澄清 multiModel 实际选择多模态生成端点，避免被理解为多模型编排 |
| 2026-07-04 | Spring AI Alibaba Website | #277 | 让官网配置说明与运行时语义保持一致 |
| 2026-07-07 | Spring AI Extensions | #286 | 修复 DashScope 已有 Pipeline 追加文档成功返回但实际未入库的问题，并补充回归测试 |
| 2026-07-17 | AgentScope | #2106 | 为长对话 WebUI 增加可访问的回到底部控制，并处理内容增长与输入区布局 |
| 2026-07-17 | Mem0 | #6322 | 修复 Structured LLM 忽略标准 OPENAI_BASE_URL 的问题，并增加配置优先级回归测试 |
其中，Spring AI Extensions #286 是一次完整的问题闭环：从复现“接口成功但文档没有进入知识库”，到追踪 Pipeline 创建、managed_ingest 和异步任务状态，再确认已有 Pipeline 应调用 PUT /documents，最后用单元测试与真实百炼知识库验证修复。
Mem0 #6322 则体现了配置兼容问题的处理方式：先确认普通 OpenAI Provider 与 Structured Provider 的行为不一致，再明确配置优先级，移除已废弃变量的隐式回退，并用 Mock 测试证明标准环境变量确实传入 SDK。
评审中的贡献
截至统计日期，还有 18 个 PR 处于 Open 状态。它们代表已经提交给社区的工作，但在合并前仍然只是候选改动，不能写成上游已经采用的成果。
MCP 与 AI Gateway
我在 LiteLLM 提交的改动集中在协议完整性与代理安全：
Agent Runtime 与状态一致性
- Spring AI Alibaba #4791：从不完整 Checkpoint Message 回滚时恢复一致状态。
- Spring AI Alibaba #4796：在 Agent 链路中保留 Gemini Thought Signature。
- Hermes Agent #63918：传播已完成 Future 中保存的 MCP Timeout。
- Hermes Agent #63956：在持久化前校验导入的 Session 值。
- Hermes Agent #64358：限制 Kanban 附件存储路径，避免越界删除风险。
- Hermes Agent #63836：支持 Twilio Messaging Service Sender。
- Agno #8772：避免把
CustomEventYield 错误混入工具结果。 - Browser Use #5144：保留敏感信息脱敏规则的优先级。
- Mem0 #6324：处理 TypeScript OSS Embedding Cache 中与原型属性同名的 Key。
Agent WebUI 与多用户隔离
我的贡献方式
这些贡献虽然分布在 Java、Python、TypeScript 和文档仓库中，但处理路径基本一致：
- 从真实使用场景或 Issue 中确定可复现的问题，而不是先写补丁再寻找理由。
- 阅读调用链和现有测试，区分根因、表象与兼容边界。
- 把修改限制在最小行为面，避免在 Bug Fix 中混入无关重构。
- 为配置优先级、状态恢复、协议分页、编码边界等问题补充回归测试。
- 在 PR 中写明验证命令、风险、兼容性和没有覆盖的范围。
- 根据 Maintainer Review 继续修订；未合并的方案始终保留“评审中”标记。
我更关注那些不容易在 Demo 中暴露、却会在生产环境形成真实故障的边界：流式取消后的状态一致性、多租户工作区隔离、代理层凭据处理、MCP 内容类型与分页、LLM Provider 配置优先级，以及 Agent 输出到确定性执行之间的责任划分。
开源治理计划
接下来的重点不是继续增加 Fork 数量，而是提高贡献的完成度：
- 跟进评审中的 PR，补充 Maintainer 要求的测试与兼容说明。
- 为个人公开源码仓库补齐清晰的 License、贡献指南与版本说明。没有 License 的公开仓库只是源码可见，不代表已经授权复制、分发或衍生使用。
- 继续把个人项目中验证过的 Agent Runtime、MCP、Memory 和可观测性问题还原成上游可接受的最小补丁。
- 定期更新本页，保持“已合并”“评审中”“关闭未合并”的状态准确。