首页
看点啥
插画图片
首页 看点啥 我开源了一套 AI Agent 框架:有性格 有规则 还能自己造工具

我开源了一套 AI Agent 框架:有性格 有规则 还能自己造工具

2026-07-14 0

大家好,我是张泽钰律师。日常办案件,业余写Python。法律人的思维方式和AIAgent治理意外地匹配——核心都是同一个问题:怎么给一个自主实体授权,同时防止它乱来。

我开源了一套 AI Agent 框架:有性格、有规则、还会自己造工具

这就是我构建OpenSymphony的初始想法,我构建并MIT开源了这个Agent框架。已在PyPI发布(pipinstallopensymphony),395个测试跑通。

痛点在哪?

市面上大部分Agent框架解决的是"编排"问题——怎么把LLM调用串起来。几乎没人解决一个更难的问题:Agent是谁?它遵守什么规则?它做错了谁来拦它? 靠人来拦是不现实的,靠它自己自觉更是痴人说梦。

用过LangChainAgent的话,应该遇到过这些:

-不一致:昨天还好用的Agent今天变成了另一个人。Promptdrift是真实存在的
-不可审计:Agent做了一个决策,没有记录为什么。没有先例,没有审查
-不安全:你可以在systemprompt里说"小心一点",但没有任何结构性机制阻止风险操作
-不成长:Agent不会学习。同样的错误反复犯

OpenSymphony用三个架构支柱来应对:Soul(灵魂)、Governance(治理)、Self-evolution(自我进化)。

支柱一:Soul——持久的Agent身份

Agent的性格不是一段prompt。是一个YAML文件,编译成行为约束。

#souls/my_agent.yamlid:my_agentname:MyAgentarchetype:CodeReviewerthinking_framework:|Youareacodereviewerfocusedonsecurityandcorrectness.Rules:1.Flaganyunvalidateduserinput2.Checkforraceconditionsinconcurrentcode3.Preferreadabilityoverclevernessvalues:-Securityfirst-Evidence-basedreview-Constructivefeedback

thinking_framework是操作逻辑,values是优先级冲突时的排序原则。还可以定义vetoconditions——硬性阻止某些操作的开关。

这不叫promptengineering。SoulCompiler把YAML编译成结构化的行为框架,跨会话、跨session持续有效。Agent不会忘记自己是谁。

内置了13个Soul:themis(法律推理)、athena(策略)、crit(对抗审查)、shield(安全)、code(实现)、novelistscreenwriter等等。每个都有自己的思考框架、价值层级和否决条件。

打个法律上的比方:Soul就像职业行为准则。律师不会接了案子才临时想"律师-当事人保密义务是什么"。它是框架自带的。这里也一样。

支柱二:Governance——结构化决策

这部分最能体现法律背景带来的差异。

律所里,决策走层级。助理起草,资深合伙人审查,风险委员会标记冲突,先例指导后续判断。OpenSymphony做同样的事:

Request→Gateway→[IntentBridge][Governance]→Runtime→Kernel→Response↑Voting/Precedent/Defense

治理层有四个机制:

VotingMechanism——多个Agent投票决策。可配多数规则和超时。三个Agent里两个说"这个操作安全",就通过。反对意见被记录。

PrecedentStore——历史决策变成可搜索的先例。Agent下次遇到类似决策时,检索相关历史。这就是普通法的运作方式——staredecisis(遵循先例),只不过用在AIAgent上。

DefenseLayer——每个操作被分类为saferiskydangerous。Risky操作需要额外审查。Dangerous操作除非人类覆盖否则直接拦截。

HITLManager——高风险操作需要人工确认。Agent提议,人决定。

fromopensymphony.kernelimportSymphonyKernelkernel=SymphonyKernel()kernel.load_souls("souls/")#请求经过治理层后才执行response=kernel.chat("crit","Shouldwedeploythisuntestedchangetoproduction?")

当你问critAgent能不能上线未经测试的代码,DefenseLayer标记为risky。VotingMechanism可以轮询多个Agent。PrecedentStore调出类似历史决策。HITLManager可以要求你签字。

我们要达到的效果就是:没有哪个Agent能独自做出不可逆决策。

支柱三:Self-Evolution——Agent自己造工具

ToolWorkshop让Agent在运行时创建、测试、部署Python工具。

Agent遇到当前工具集解决不了的任务。它自己写一个新的,测试,注册到工具库。不需要人类介入——但治理仍然适用。新工具走同样的风险分类流程。

这很关键——你不可能预判Agent未来需要的所有工具。替代方案要么是维护一个巨无霸工具集(维护噩梦),要么给Agenteval权限(安全噩梦)。Workshop是折中方案:Agent可以扩展能力,但在沙箱里,有资源限制和治理监督。

架构:洋葱模型

每个请求经过同心层:

┌─────────────────────────────────────────────────┐│Gateway(HTTP/WebSocket/CLI)││└─HumanAdapter—IntentBridge(NL→struct)│├─────────────────────────────────────────────────┤│Governance││├─VotingMechanism—多Agent决策││├─PrecedentStore—可重用的历史决策││├─DefenseLayer—风险评估││└─HITLManager—人在回路│├─────────────────────────────────────────────────┤│Runtime││├─AgentPool—并发Agent管理││├─TaskScheduler—优先级队列││└─AgentSandbox—资源限制│├─────────────────────────────────────────────────┤│Kernel││├─SoulCompiler—YAML→行为规则││├─LLMRouter—云端+本地模型││├─Memory(L1/L2/L3)—三层存储││└─ToolWorkshop—Agent自行造工具│└─────────────────────────────────────────────────┘

IntentBridge把自然语言转成结构化意图。Governance审查意图。Runtime带资源限制执行。Kernel做实际工作:Soul编译、LLM路由、记忆检索、工具管理。

没有任何请求能绕过Governance到达Kernel。

三层记忆

Agent需要不同时间尺度上的记忆:

层级存储用途
L1内存当前会话上下文
L2SQLite经验数据库,支持全文搜索
L3云端API长期持久记忆

L1快、短命。L2存储Agent学到的教训——"这个API限流100req/min"、"这个用户喜欢简洁回复"。L3是可选的云存储,跨会话持久化。

PrecedentStore横跨L2和L3。Agent做决策时存下来。类似情景出现时检索出来。随时间推移,系统建立自己的判例法。

LLM路由——云端和本地都支持

LLMRouter同时支持云端API和本地模型。不同Agent可以路由到不同模型——简单的分类任务用本地7B模型,复杂推理走云端。

这对成本和隐私都很关键。一个治理系统如果每次决策都走第三方API,那就是个数据泄露通道。本地模型把敏感决策留在你的硬件上。

普通消费级硬件就能跑。我在一台16GBRAM的Macmini上开发和运行OpenSymphony。本地推理不快,但能用。

395个测试意味着什么

测试覆盖治理层、Soul编译、记忆层级、LLM路由和ToolWorkshop。治理逻辑需要确定性测试——你不能靠LLM的概率性输出来验证DefenseLayer是否正确拦截了危险操作。

gitclonecdopensymphonypipinstall-e".[dev]"pytest#395passing,6knownintent-bridgefailures

##快速开始

pipinstallopensymphonypython-mopensymphony.gateway.http

定义YAMLSoul,加载,跟你的Agent对话。治理层是可选的——可以先不用,等需要时再叠加投票、防御或HITL。

fromopensymphony.agents.soulimportSoulfromopensymphony.agents.soul_compilerimportcompile_soulsoul=Soul.from_yaml("souls/my_agent.yaml")prompt=compile_soul(soul,output_mode="agent")

作为律师来造这东西带来什么有趣的变化?

法律系统花了大概900年来解决一个问题——AIAgent现在也面临这个问题:怎么给自主实体决策权,同时防止滥用?

法律的答案是结构性的。宪法、先例、投票流程、辩护律师、上诉审查。而不是在systemprompt里写"请小心"。

OpenSymphony借鉴了这些模式。Soul是职业行为准则,PrecedentStore是判例法,DefenseLayer是风险评估,VotingMechanism是协商民主,HITLManager是司法审查。

目标不是通过promptengineering让Agent"有道德"。而是用结构性的约束,让坏行为难以发生、可审计、可修正。

现状和路线图

框架MIT许可,代码在GitHub。13个内置Soul覆盖代码审查到创意写作等场景。应用模块已有小说产线和内容生产管线。

现在能用的:Soul系统、全量治理层、三层记忆、LLM路由、ToolWorkshop、HTTP/WebSocket/CLI网关。

规划中的:更多Soul、更好的本地模型集成、用语义搜索扩展先例检索。

如果你也在做Agent系统,对agent治理有想法——这个项目的GitHubIssues和PR都开着,欢迎来聊聊。

喜欢(0)

上一篇

做 AI Agent 时:我终于搞懂了 Tracker 的真正作用

做 AI Agent 时:我终于搞懂了 Tracker 的真正作用

下一篇

在 ESP32 上跑自定义唤醒词:从 TFLite 到离线语音唤醒:一个下午搞定

在 ESP32 上跑自定义唤醒词:从 TFLite 到离线语音唤醒:一个下午搞定
猜你喜欢