最近在群里讨论到同步与异步处理的差异，及如何实现异步化提高效率，特别是在网络请求和大规模数据处理场景下，分享一下LangChain同步转异步的处理方案：

以Embeddings模块为例（图2），除了提供embed_documents函数外，还要提供其对应的async embed_documents函数，在这里，langchain使用run_in_executor来实现同步转异步（图3），这其实是一个统一的逻辑，如果你的系统比较大，或者是做lib开发，可以参考langchain的这种方案。

Link: github.com

而在这之前，langchain很多模块的异步功能都是直接copy的同步版本逻辑写的，至此产生了很多冗余代码，当然现在还有很多community的异步逻辑也是不统一的👀，比如智谱的（图4）。

最近有朋友向我咨询，如何构建一个更pythonic的工程化项目，作为一个有重度代码洁癖，发过n次Python包的开发者，下面分享一个自己一直在用的模板仓库，我所有的Python项目都是用这个模板创建的：

3PG（Python Packages Project Generator），结合了最先进的库和 Python 最佳开发实践。Github: github.com

开发特性：
1.支持 Python 3.7 及更高版本。
2.使用 Poetry 作为依赖管理器。参见 pyproject.toml 和 setup.cfg 中的配置。
3.更快的格式化工具，使用 ruff 自动代码风格，替代 black、isort 和 pyupgrade。
4.开箱即用使用的 pre-commit 钩子，用于代码格式化。
5.类型检查使用 ruff；docstring 检查使用 darglint；安全检查使用 safety 和 bandit。
6.使用 pytest 进行测试。
7.开箱即用的 .editorconfig、.dockerignore 和 .gitignore 文件，你不必担心这些事情。
8.dockerfile。

部署特性
1.GitHub 集成：问题和 pr 模板。
2.使用预定义的 构建工作流 作为默认的 CI/CD 的 Github Actions。
3.使用makefile管理项目，已经为安全检查、代码风格检查、代码格式化、测试、linting、docker 构建等设置好了一切。
5.使用 @dependabot 保持依赖项始终更新。
6.使用 Release Drafter 自动发布说明。你可以在 release-drafter.yml 中看到标签列表。与 Semantic Versions 规范完美配合。

开源社区特性
1.开箱即用的 Pull Requests 模板 和几个 Issue 模板。
2.自动生成的文件，如：LICENSE、CONTRIBUTING.md、CODE_OF_CONDUCT.md 和 SECURITY.md。
3.Stale bot，在一段不活跃后关闭遗弃的问题。
4.使用 Release Drafter 的 Semantic Versions 规范。

本来想给之前写的 cache orm 框架重新取个名字叫 cao（cache of orm），发个新的 lib，然后本能地去 pypi 搜了一下，很可惜这个名字已经被用了（已经猜到了），但是没想到，看了一下这个 cao 的 maintainer，各种抽象的词都被他发了个包...

我最近将之前的MultiAgent编排系统迁移到LangGraph，利用LangChain全家桶带来的便利性。同时，也分享一个我给LangGraph提的语法优化建议，是一个很有趣且简单的点，希望对你的Python开发有帮助：github.com

我的提议重点是引入一个定义清晰的AgentState类，替代旧有的dict，以便更好地维护复杂系统的数据。

同时，通过枚举和pydantic BaseModel，我们可以轻松地避免一些数据声明的低级错误和数据传输问题，确保正确性。这对复杂系统的开发维护来说至关重要。

自从去年7月 pydantic 发布了v2之后，breaking 的更新导致很多库需要做兼容方案，下面分享一个对 Python SDK 开发者来说，十分方便的 pydantic 版本兼容方案：

哈佛医学院的一个开发者开发了名为 pydantic-compat 的包。通过下面的方式，你可以十分轻松的进行 pydantic v2 的版本兼容，GitHub：github.com

它主要用于将 namespace 从一个API转换为另一个API。它将 v2 API 反向移植到 v1 (因此你可以在pydantic1运行时中使用 v2 名称)，并将 v1 API 转发到 v2（因此您可以在 v2 运行时中使用 v1 名称而不会出现弃用警告）。

当然，同时我们也可以看看当前项目的一些兼容方案。OpenAI 和 FastAPI 采用了通过构建 _compat.py，来重命名pydantic v2 的一些新特性，而 LangChain 则通过直接使用v2中 的 pydantic.v1 namespace，使用 pydantic.v1 的 namespace 虽然更加方便，但是LangChain当前SDK内部无法直接使用 v2 的特性，不过预期今年十月份会兼容 v2。

LangChain 解决方案：github.com

今天看到一些关于讨论模型价值观的问题，记录一下一些想法。

各种 AI wrapper 程序模拟人的行为，比如虚拟女友，其目标函数就是开发者对应的价值观，如果希望赋予某些情感，或许会有一个 n 边图，每一个边可以代表一种情绪的值，比如说愤怒指数，0-100 的刻度，不同的范围允许做不同类型的事情，可以构建一个规则表，这个程度已经可以做出一个还不错的状态了（哄哄模拟器，虽然感觉还是有点无理取闹），如果再 Agent 一点的思路，做一做 self iteration，构建可迭代的规则表，就能比较明显的感受到你的虚拟女友是一个“可以为了你改变的人”。

进一步地，Robot & AI Agent 在有了目标函数，比如对于一个战斗机器人来说，构建对应的价值观之后，其目标函数或许是不杀“好人”，如果根据目标函数构建自迭代规则表，在自迭代过程中的 self-criticism 和 thought，是否会让 ta 走向机械公敌的状态？当前 ft 就能让模型丧失安全边界，如此低的成本，在拥有人格化的能力之后，人工智能的安全和伦理是一个特别严峻的问题。

顾问的表述听起来比 AI 助理的叙述更合适一些

感慨一下，每天都有新的技术、研究、应用不断出现，越来越觉得 Agent framework 需要在技术的延长线上创新，面相未来设计，让子弹飞一会，等到模型推理能力上去，推理成本下来的时候，你就会突然有一种"下一步走对了的感觉"

langchain 不太推荐用 ta 的 Agent，Agent 还是搭配 langgraph 之类的框架自己搭会好一点，langchain 出 ReAct Agent 的时候已经是很早的时候了，prompt 还是基于 base 模型设计的，也没有 JSON output 的统一共识，所以有很多技术债的历史遗留。langgraph 的推出其实也是希望构建一种更好的 Agent App 开发范式，充分发挥 Langchain infra 的优势。

我觉得最方便的方式就是直接copy相关类出来二开哈哈哈

分享一下符尧的观点: 下图中 Claude3 的视觉能力负责将图像中的文本转录成 JSON 格式的文本。有很多高质量的教科书还没有数字化，其中许多只是扫描，所以你猜训练下一代模型的数据会在哪里。

原文: twitter.com