teionarr/langchain-expert

大多数 LangChain 的审查建议都是风格指南 —— 导入顺序、命名、“使用最新的 API”。这并不是 生产级 agent 出现故障的地方。 该技能围绕真实代码库中缺陷**实际**聚集的位置进行组织，而这一点 —— 在对从 152k star 的平台到 1k star 的 agent 模板等 22 个代码库的审计中 —— 几乎从未出现在架构层面： | 故障类别 | 在实际项目中的表现 | |:--|:--| | 🎭 **声称提供了保证，但实现薄弱** | `or True` 悄无声息地使错误分类器失效 · 解析失败默认给出一个确定的结论 · 通过 `startswith` 来强制执行“只读” | | ⏱️ **逻辑正确，但生命周期或频率错误** | 没有逐出机制的缓存 · 每次 LLM 调用都进行一次数据库提交 · 每个请求都在修改共享的 singleton | | 🔓 **假设已授权，但从未进行验证** | 一个 handler —— 或一个 **agent 工具** —— 通过 id 获取资源而没有检查所有者 | 在整个审计过程中，第三类故障产生了**所有**的高严重性发现，而大多数审查清单完全忽略了这一点。 一旦将其作为一项实践记录下来，**接下来 6 次审计中的 5 次**都产生了此类发现 —— 而第 6 次则是真 实的 N/A。*（这里统计的是该视角是否被触发，而不是它是否正确 —— 请参阅 VALIDATION.md 中的警告。）* → [VALIDATION.md](VALIDATION.md) ## 快速开始 **使用 agent 工具（如 Claude Code 等）** —— 将此文件夹放入你的技能目录中并按名称调用它，或者直接将 agent 指向 `SKILL.md`： ``` Review this repo with langchain-expert. ``` **手动执行** —— `SKILL.md` 是一个独立的检查清单。从头到尾按照流程执行即可。 ## 审查的工作原理 ``` flowchart LR A[Detect shape] --> B[Detect era] B --> C[Verify APIs
before asserting] C --> D[Walk the
23 practices] D --> E[Qualify each
candidate] E --> G[Validate
the fix] G --> H[Red-team in a
fresh context] H --> F[Report
≤7 findings] style A fill:#1f6feb,color:#fff style E fill:#8957e5,color:#fff style H fill:#da3633,color:#fff style F fill:#238636,color:#fff ``` **流程**与实践同样重要： - **首先判断结构。** 原生图应用不是 `create_agent` 应用 —— 在不需要的地方强求导入 middleware 是产生误报的首要原因。 - **在断言前先进行验证。** 一个自信但错误的修正比不审查更糟糕。原则是稳定的；kwargs 则不然。 - **在投入精力前先进行限定。** 它是否能在*默认*路径上可达 —— 真正的默认值和实际的调用路径，而不是隐藏在默认关闭的 flag 之后的死代码？这一项检查比评分标准中的任何其他内容都能消除更多被夸大的严重性。 - **永远不要推荐你尚未追踪过的修复方案。** 连续九次审计都给出了错误的修复方案；其中两次本会导致服务中断。 - **在发送之前，在一个全新的上下文中进行红队测试。** 独立性是其机制 —— 重新阅读你自己的发现有助于对其进行辩护。要做好 bug 依然存在以及报告会发生变化的准备。 - **永远不要捏造发现。** *“两个发现加上一长串 N/A 列表”* 也是一次有效的审查。 ## 包含内容 ``` SKILL.md the skill — procedure + 23 practices (start here) VALIDATION.md the golden set: every repo audited, findings, lessons references/notes.md rationale, evidence, verified API signatures references/gold-standard-agent.py a reference agent to copy the shape from ``` ## 验证 此技能**已针对真实代码进行了测试，并且也记录了遗漏的情况。** | | | |:--|:--| | 审计的代码库 | **22** | | 高严重性发现 | **全部**属于授权类别 | | 处于协调披露流程下的代码库 | **9** | | 已提交 / 已向上游披露 | 1 个公开 issue + PR · 4 个私下安全通告 · 5 个已准备好的补丁包 | | 已由他人报告 | 2 | | 干净的对照案例 | 2，外加 1 个正确的 **N/A** | | 外部结论（已合并修复 / 安全通告 / 维护者确认） | **1** — pipeshub-ai 确认并修复了一个真实的发现（[PR #2743](https://github.com/pipeshub-ai/pipeshub-ai/pull/2743)）；一个 bug，而不是评分 | 评分标准的每一次更改都可以追溯到揭示该漏洞的具体审计过程。完整分析（包括每个代码库的 LangChain 深度评级）→ [VALIDATION.md](VALIDATION.md) ## 来源 基于 Anthropic 的 `expert-langchain` 技能构建，并扩展了第三种故障类别（授权）、一个严重性限定步骤，以及 [VALIDATION.md](VALIDATION.md) 中的验证测试工具。 ## 许可证 [MIT](LICENSE)

标签：DLL 劫持, LangChain, 代码审查, 大语言模型, 开发规范, 轻量级, 防御加固