文章介绍了一种在运行时动态修改Python函数源代码的技巧，通过使用compile和exec函数实现。这一技术可以增强AI机器人的灵活性，使其能够生成并执行代码，并访问当前环境。尽管这为LLM驱动的代理和生成式UI带来了新的可能性，但也引发了严重的安全隐患。

标题：Python运行时动态修改函数源代码的技巧

在这篇博客中，作者分享了一个强大的Python技巧：在运行时动态修改函数的源代码。通过使用compile和exec函数，作者能够构建更灵活的AI机器人，如ToolBot，这些机器人可以生成并执行代码，并访问当前环境中的变量。虽然这项技术为基于LLM的代理和生成式UI带来了令人兴奋的可能性，但也引发了严重的安全问题。

技术原理

每个Python函数都有一个.__code__属性，它包含了函数的字节码。通过修改这个属性，可以在运行时动态替换函数的源代码。具体步骤如下：

1. 编译新代码：使用compile函数将新的源代码字符串编译为字节码。
2. 执行编译后的代码：使用exec函数将编译后的代码导入到一个特定的命名空间中。
3. 替换原函数：将原函数替换为命名空间中的新函数。

应用场景

作者在开发LlamaBot时，发现原有的AgentBot实现不够理想，因为它将函数执行、函数调用决策和用户响应生成等功能混合在一起。为了解决这个问题，作者创建了ToolBot，它专注于工具选择而不是执行。ToolBot的核心思想是将工具的选择与执行分离，从而提供更大的灵活性。

关键工具：write_and_execute_code

ToolBot中最强大的工具之一是write_and_execute_code，它允许LLM生成Python函数并在当前运行时环境中执行。这个工具的关键在于它能够访问当前命名空间中的所有全局变量，从而使得生成的代码可以直接操作现有的数据和变量。

安全问题

尽管这项技术非常强大，但也存在严重的安全隐患。恶意代码可以直接在运行时环境中执行，可能对系统造成巨大破坏。作者提到，未来可能会使用Restricted Python来增强代码的安全性。

总结

通过这次探索，作者学到了以下几点：

1. Python的运行时环境比想象中更加灵活，能够动态编译和执行代码。
2. 构建有效的LLM代理不仅仅是关于AI，还需要深思熟虑的系统设计。
3. LLM是学习的好工具，但必须学会如何利用它们进行学习。

这项技术为AI项目带来了新的可能性，但同时也需要谨慎对待其潜在的风险。

评论主要围绕自修改代码（SMC）及其在不同编程语言中的应用展开，观点多样且涉及多个方面：

1. 自修改代码的历史与现状：

   • 评论1提到自修改代码曾是LISP相关AI领域的一部分，但因安全问题逐渐被弃用，部分技术保留在动态编译中。
     • "Wasn't SMC one of the LISP-associated AI fields a few decades ago? iirc it's been mostly abandoned due to security issues, but some of it survives in dynamic compilation."
   • 评论3强调Lisp在AI编程中的历史地位，认为其自修改代码的特性非常酷。
     • "Once you see how cool that is, then you can begin to appreciate why Lisp was the defacto standard for AI programing all the way back in the 1960s!"

2. Python中的自修改代码：

   • 评论2讨论了如何在Python中动态修改代码，并提到处理依赖和动态注入功能。
     • "Aka I just learned how to modify python code whilst it's running."
   • 评论9分享了通过修改函数字节码来强制类型安全的实验，但指出性能问题使其不适合生产环境。
     • "I used live patching of the function byte code to enforce type safety in python as an experiment."

3. 自修改代码的实用性与风险：

   • 评论11批评了自修改代码的滥用，认为调试这类程序会非常困难。
     • "Just cause you can do something doesn't mean you should. I send thoughts and prayers for the people debugging programs where this is in place."
   • 评论13提到Python的安全性问题，认为其不友好的安全模式是停止使用Python的原因之一。
     • "Python being riddled with security anti-patterns -- or at least security-unfriendly ergonomics -- is one reason I tried to stop working with it."

4. 其他语言中的自修改代码：

   • 评论15询问除了Lisp外，其他语言是否也能实现自修改代码。
     • "Other than Lisp, is it possible to do this in other languages?"
   • 评论16提到在大型函数或方法中应用小补丁的用例，认为覆盖代码会导致代码冗余。
     • "Another use case is applying small patches to a large function or method. Overriding would mean copy pasting largely similar code."

5. 对自修改代码的质疑与困惑：

   • 评论7质疑了自修改代码的实际用例，认为可能是年轻程序员对OOP不熟悉导致的复杂实现。
     • "Someone explain to me, an old, aging programmer old enough to know UML, why this isn't some we presume very young person who has no idea how to write OOP coming up with some horrible convoluted way to do something routine?"
   • 评论17认为文章内容复杂且无实际意义，作者可能只是发现了eval()但过度复杂化。
     • "As far as I can tell, the author discovered eval() but is making it more complicated for no reason?"

总结：评论中对自修改代码的态度褒贬不一，既有对其历史地位和灵活性的认可，也有对其安全性和调试难度的担忧。Python和Lisp是讨论的焦点，其他语言的应用也被提及。