PraisonAI 行为对齐机制解析TypeScript SDK 未生效选项的检测、告警与棘轮治理【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAIPraisonAI 的 Python 版 SDKpraisonaiagents与 TypeScript 版 SDKpraisonai-ts共享同一套对外 API 契约。为了让 TypeScript 侧名字已导出、参数已存在、行为却未生效的选项不再静默潜伏仓库建立了一套三层对齐检查其中src/praisonai-ts/BEHAVIOUR_PARITY.md行为对齐报告专门统计那些为对齐 Python 而接受、但尚未真正落地的选项。阅读本文后你将掌握这套行为对齐机制的设计原理、UNHONOURED_OPTIONS账本的读写方式、运行时告警与静默开关以及如何通过python -m praisonai._dev.parity.behaviour命令配合棘轮规则推进对齐工作。一、为什么需要三层对齐检查名称、签名之外的第三个维度PraisonAI 用三份文档把 TypeScript SDK 对 Python SDK 的对齐切成三个可独立验证的层次BEHAVIOUR_PARITY.md负责补齐前两层都看不见的漏洞检查层对应文档检测内容盲区名称对齐PARITY.mdPython 导出的符号名是否在 TS 侧存在✅ exported仅代表名字存在不代表可用名字在能力可能是空壳签名对齐SIGNATURE_PARITY.mdPython 构造器/方法参数是否在 TS 侧存在参数在可能被接受后直接忽略行为对齐BEHAVIOUR_PARITY.md被接受的选项是否真的改变了代码行为——正如行为检查器源码behaviour.py所述一个被接受、被类型化、被文档化、然后被忽略的选项能同时通过前两关——这正是当初76 个此类选项悄无声息累积下来、而任何数字都不曾变动的根本原因。行为对齐这一层存在的意义就是给这些沉默的缺陷装上计数器。二、核心账本UNHONOURED_OPTIONS与 parity-notice 工具集行为对齐的单一数据源是 TypeScript 侧的 parity-notice.ts 中手写的账本常量export const UNHONOURED_OPTIONS: ReadonlyRecordstring, readonly string[] { AgentTeam.__init__: [ knowledge, guardrails, web, reflection, caching, learn, ], Task.__init__: [ autonomy, web, reflection, planning, ], } as const;该文件同时导出一组配套 API构成账本 运行时告警 可查询状态的完整闭环unhonouredFor(surface: string): readonly string[]—— 返回某个表面surface尚未生效的选项列表为空数组表示该表面干净unhonouredCount(): number—— 统计全仓库被接受但未生效的选项总数notYetHonoured(surface, option, detail?)—— 记录调用方传入了某选项但 TS 实现尚未落地并每个surface, option组合每个进程只警告一次内部用seen集合去重输出形如[praisonai] Agent: option ... is accepted for parity with the Python SDK but is not yet honoured in TypeScript.的警告unhonouredOptions(): string[]—— 返回本次进程中已上报过的全部Surface.option键排序后resetParityNotices(): void—— 测试辅助函数清空已记录键以便告警再次触发环境变量PRAISONAI_PARITY_SILENT1或true—— 静默开关适合测试环境批量压制告警同时unhonouredOptions()依然可被代码查询即可以静音但不能假装没发生。在构造器中接入账本的推荐写法源码注释中的示例是if (config.sandbox ! undefined) notYetHonoured(Agent, sandbox);这样任何被接受但不生效的选项都会在运行时自我声明而不是静默消失。三、检查器与棘轮python -m praisonai._dev.parity.behaviourPython 侧的行为检查器位于 src/praisonai/praisonai/_dev/parity/behaviour.py它读取上述 TypeScript 账本、扫描src/praisonai-ts/src下的全部.ts源码然后生成BEHAVIOUR_PARITY.md与behaviour-parity.json两份报告。核心命令# 重新生成报告Markdown JSON python -m praisonai._dev.parity.behaviour --write # 校验报告是否过期 / 总数是否上升 python -m praisonai._dev.parity.behaviour --check命令支持四个参数参数作用--write重新生成BEHAVIOUR_PARITY.md与behaviour-parity.json--check若报告过期或总数上升则失败退出--allow-growth允许--write提升已提交的总数须在 PR 中说明理由总数下降永远不需要该标志--repo-root指定仓库根目录默认自动探测机制上它是一把棘轮ratchet已提交报告behaviour-parity.json中的total是下限当前总数只许下降、不许上升。--write同样强制执行该棘轮——因为它在每次推送到 main 时都会运行并自动提交若没有这道闸数量上升就会靠写进去而不是靠论证进入主干。--check的失败信息会明确指出某选项被接受但被忽略能通过名称与签名两道关卡因此这是唯一能看到它的检查。检查器的防作弊设计账本解析并非简单的正则逐行匹配而是结构化扫描其注释记录了两次踩坑教训表面surface不能被解析丢失冒充进度若某个Surface: [...]条目因解析器不认识而漏读总数会下降看起来像进步、还能被--write固化。因此扫描器按大括号深度逐字符解析对象字面量并用两个独立手段交叉校验_verify_parse用另一套独立正则_KEY_RE重新读出账本声明的所有表面与扫描结果比对不一致即报错对 TypeScript 源码中每个unhonouredFor(X)调用点做反向核对——账本仍声明 X、但解析没看到它就判定为解析失败绝不当作关闭。键的引用风格不设限JavaScript 对象键既可以是带引号字符串也可以是裸标识符Handoff: [...]与Handoff: [...]都合法引号也允许 三种。解析器全部兼容否则某种风格会让表面悄悄掉出计数再次伪装成进度。注释剥离_strip_comments在保留所有偏移量与字符串的前提下清空//与/* */注释被注释掉的条目不得计入真实条目也不得因注释紧邻而丢失。拒绝零选项误报如果账本结构变化导致一个表面都没解析出来直接抛出LedgerError——绝不允许在解析器失配时报出无事可做。此外凡是在UNHONOURED_OPTIONS顶层出现非Surface: [...]形式的记号、表面重复声明、选项名不符合[A-Za-z_][A-Za-z0-9_]*规范与字符串总数不一致等都会引发LedgerError把潜在的错误消灭在生成阶段。四、当前工作队列10 个未生效选项报告摘要显示当前账本共登记10 个尚未生效的选项SurfaceOptions not yet acted onAgentTeam.__init__6Task.__init__4Total10另加17 个部分生效选项见第五节。每个账本条目就是一个工作单元实现它 → 从账本删除 → 补一条证明该选项确实改变代码行为的测试 → 重新生成报告。4.1AgentTeam.__init__6 项knowledge、guardrails、web、reflection、caching、learn这 6 个选项在 AgentTeam 构造器中通过 team.ts 的统一循环上报const accepted: Array[string, unknown] unhonouredFor(AgentTeam.__init__) .filter((name) !HONOURED_HERE.has(name)) .map((name) [name, (config as unknown as Recordstring, unknown)[name]] as [string, unknown]); for (const [name, value] of accepted) { if (value ! undefined value ! false value ! null) { notYetHonoured(AgentTeam, name, TEAM_OPTION_NOTES[name]); } }其中HONOURED_HERE集合把已在团队层面落地的选项autonomy、toolsRunOn、memory、context、hooks、planning、execution、runOn、managerLlm从告警循环中排除避免对已实现的行为误报。值得注意的源码细节TEAM_OPTION_NOTESteam.ts揭示了这 6 项未生效并非 TypeScript 侧的单方面落后——Python 参考实现同样不在团队级别应用它们其构造器会记录类似AgentTeam received [...] but does not yet apply them at the team level; pass these to individual Agent(...) instances instead的提示。也就是说在这 6 个选项上实现团队级行为反而会偏离参考实现正确的替代方案是把这些能力传给单个Agent(...)实例例如knowledge的提示明确写道Python does not apply it at the team level either; pass knowledge to individual Agent(...) instances.。这一结论与 team-options.ts 中团队级execution/hooks/context已实现解析器的现状互为印证说明团队表面的对齐工作是从这些选项开始的。4.2Task.__init__4 项autonomy、web、reflection、planningTask 侧的做法是把账本直接当作引擎级选项列表。在 types.ts 中/** Options Task accepts for parity but whose behaviour lives in the execution engine, not in Task. */ const ENGINE_LEVEL_OPTIONS unhonouredFor(Task.__init__) as ReadonlyArraykeyof TaskConfig;构造器在 types.ts 中遍历该列表凡是被调用方传入的选项就上报notYetHonoured(Task, option)。注释点明了分工逻辑这些选项的行为归属地是执行引擎team-runner 等而非 Task 对象本身因此 Task 暂存它们、由引擎消费——decision就是一个已落地的例子runner 读取它驱动路由表。此外taskType与字符串形式的guardrails需要 LLM 评判器也会被单独上报属于部分生效的范畴。五、Partial 表17 个部分生效的选项部分生效partial的判定依据是源码中notYetHonoured(Surface, Option, why)带三个参数的调用——选项对某些输入有效、对其余输入则自我声明。检查器用正则_PARTIAL_RE从全部 TS 源码中收集这些调用点behaviour.py并把它们与账本分开统计因为并非完全缺失。当前 17 个分布如下SurfaceOptionDeclared inAgentcontextsrc/praisonai-ts/src/agent/simple.tsAgentguardrailssrc/praisonai-ts/src/agent/simple.tsAgentknowledgesrc/praisonai-ts/src/agent/simple.tsAgentmemorysrc/praisonai-ts/src/agent/simple.tsAgentreasoningEffortsrc/praisonai-ts/src/agent/simple.tsAgenttoolConfigsrc/praisonai-ts/src/agent/simple.tsAgentwebsrc/praisonai-ts/src/agent/simple.tsAgent.chatattachmentssrc/praisonai-ts/src/agent/simple.tsAgent.chatoutputPydanticsrc/praisonai-ts/src/agent/simple.tsAgent.chatseedsrc/praisonai-ts/src/agent/simple.tsAgentTeamcontextsrc/praisonai-ts/src/agent/team-options.tsAgentTeamexecutionsrc/praisonai-ts/src/agent/team-options.tsAgentTeamhookssrc/praisonai-ts/src/agent/team-options.tsAgentTeammemorysrc/praisonai-ts/src/agent/team-memory.tsAgentTeamplanningsrc/praisonai-ts/src/agent/team-planning.tsChromaMemoryragDbPathsrc/praisonai-ts/src/memory/adapters.tsTaskguardrailssrc/praisonai-ts/src/agent/types.ts几个典型的部分生效实现展示告警携带的可操作信息Agent的websimple.tstavily、exa、perplexity、parallel四个提供商可工作未知提供商则告警Unknown web search provider ... (available: tavily, exa, perplexity, parallel).Agent的memorysimple.tstrue、MemoryConfig、文件路径、Memory 实例均可用未识别的预设字符串则提示pass true, a MemoryConfig, a file path or a Memory instance.Agent.chat的outputPydanticsimple.tsJSON Schema、带toJSONSchema()的对象、zod schema 都能转换其余类型告警后忽略AgentTeam的executionteam-options.ts预设fast/balanced/thorough/unlimited与[preset, overrides]合并均可用未识别的预设名会列出全部合法取值ChromaMemory的ragDbPathadapters.tsTypeScript 的 Chroma 客户端是 HTTP-only因此该参数告警并建议改用host/port/path配置。可以看到partial 与完全未实现的差异在于前者主路径已可用仅边界输入被显式拒绝并给出替代方案因此从账本中单列统计。六、关闭一个选项的标准工作流报告把每个账本条目明确定义为一个工作单元标准流程四步实现行为让选项真正改变代码行为例如把AgentTeam.knowledge接到成员 Agent 的 KnowledgeBase 上删除账本条目从 parity-notice.ts 的UNHONOURED_OPTIONS中移除该选项名补测试证明新增一条测试证明有该选项时行为改变、无该选项时行为不变对照组思想因为账本是手写的删除本身就是一句已实现的声明必须用测试背书重新生成运行python -m praisonai._dev.parity.behaviour --write更新 Markdown 与 JSON 报告提交后总数下降即被棘轮认可。--write在检测到本次变更关闭了选项时会打印claimed closed by this change (N): Surface.option, ...并附上固定提醒本工具无法验证这一点账本为手写选项名无论如何都已出现在源码与测试中。每一项都需要一条证明选项改变代码行为的测试。——把删除这个动作的验证责任明确交给评审者与测试而不是假装检查器能自动确认。七、诚实的边界检查器不能看见的东西行为对齐机制对自身能力边界保持高度自觉behaviour.py 记录了三种曾被评估的自动验证删除候选方案及其测量结果针对当时 48 个条目选项在 src/ 中除 parity-notice.ts 外被引用0/48 会触发——签名关卡本就要求参数存在这条无法失败某个测试提及选项名0/48 会触发——同样必然通过某个不 import parity-notice 的测试提及选项名7/48 会触发——虽然能失败但其余 41 个只需在测试树任意位置出现裸标识符即可蒙混过关例如Task.web会被tools/registry.test.ts证明、AgentTeam.autonomy会被某个Agent.autonomy的测试证明。若采用等于为 85% 的删除开了绿灯还披着已验证的外衣一条注释就能满足它。结论是不加自动护栏数字保持诚实的自报。--write与--check打印本次变更声称关闭了什么交由评审者对照测试核查而不是假装验证。这份克制恰恰是这套机制的可靠性所在——它把无法机械证明的部分显式地暴露出来而不是用看似严谨的规则掩盖它。八、实践要点小结运行时可见性任何被接受但未生效的选项都会在传入时打印一次[praisonai] ... not yet honoured in TypeScript警告测试环境可用PRAISONAI_PARITY_SILENT1静音代码中仍可通过unhonouredOptions()查询治理纪律总数是棘轮只降不升需要上升必须--allow-growth并在 PR 中说明理由判断标准能通过名称与签名两层检查的选项唯一能拦住被接受即被忽略的就是行为层——因此每次新增 Python 对齐参数时要么接上实现要么登记入账并让它自我声明与 Python 的语义一致性AgentTeam的 6 个未生效选项在 Python 团队级别同样不生效正确做法是把这些能力下沉到单个Agent实例Task的 4 个选项则属于行为归属引擎Task 只负责暂存与上报。行为对齐不是简单的 TODO 列表而是一套把沉默缺陷转化为可见、可量化、只降不升的工程机制。理解BEHAVIOUR_PARITY.md及其背后的parity-notice.ts账本与behaviour.py检查器你就能在向 TypeScript SDK 新增 Python 对齐参数时既保证签名不缺也保证行为不空。【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PraisonAI 行为对齐机制解析：TypeScript SDK 未生效选项的检测、告警与棘轮治理
PraisonAI 行为对齐机制解析TypeScript SDK 未生效选项的检测、告警与棘轮治理【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAIPraisonAI 的 Python 版 SDKpraisonaiagents与 TypeScript 版 SDKpraisonai-ts共享同一套对外 API 契约。为了让 TypeScript 侧名字已导出、参数已存在、行为却未生效的选项不再静默潜伏仓库建立了一套三层对齐检查其中src/praisonai-ts/BEHAVIOUR_PARITY.md行为对齐报告专门统计那些为对齐 Python 而接受、但尚未真正落地的选项。阅读本文后你将掌握这套行为对齐机制的设计原理、UNHONOURED_OPTIONS账本的读写方式、运行时告警与静默开关以及如何通过python -m praisonai._dev.parity.behaviour命令配合棘轮规则推进对齐工作。一、为什么需要三层对齐检查名称、签名之外的第三个维度PraisonAI 用三份文档把 TypeScript SDK 对 Python SDK 的对齐切成三个可独立验证的层次BEHAVIOUR_PARITY.md负责补齐前两层都看不见的漏洞检查层对应文档检测内容盲区名称对齐PARITY.mdPython 导出的符号名是否在 TS 侧存在✅ exported仅代表名字存在不代表可用名字在能力可能是空壳签名对齐SIGNATURE_PARITY.mdPython 构造器/方法参数是否在 TS 侧存在参数在可能被接受后直接忽略行为对齐BEHAVIOUR_PARITY.md被接受的选项是否真的改变了代码行为——正如行为检查器源码behaviour.py所述一个被接受、被类型化、被文档化、然后被忽略的选项能同时通过前两关——这正是当初76 个此类选项悄无声息累积下来、而任何数字都不曾变动的根本原因。行为对齐这一层存在的意义就是给这些沉默的缺陷装上计数器。二、核心账本UNHONOURED_OPTIONS与 parity-notice 工具集行为对齐的单一数据源是 TypeScript 侧的 parity-notice.ts 中手写的账本常量export const UNHONOURED_OPTIONS: ReadonlyRecordstring, readonly string[] { AgentTeam.__init__: [ knowledge, guardrails, web, reflection, caching, learn, ], Task.__init__: [ autonomy, web, reflection, planning, ], } as const;该文件同时导出一组配套 API构成账本 运行时告警 可查询状态的完整闭环unhonouredFor(surface: string): readonly string[]—— 返回某个表面surface尚未生效的选项列表为空数组表示该表面干净unhonouredCount(): number—— 统计全仓库被接受但未生效的选项总数notYetHonoured(surface, option, detail?)—— 记录调用方传入了某选项但 TS 实现尚未落地并每个surface, option组合每个进程只警告一次内部用seen集合去重输出形如[praisonai] Agent: option ... is accepted for parity with the Python SDK but is not yet honoured in TypeScript.的警告unhonouredOptions(): string[]—— 返回本次进程中已上报过的全部Surface.option键排序后resetParityNotices(): void—— 测试辅助函数清空已记录键以便告警再次触发环境变量PRAISONAI_PARITY_SILENT1或true—— 静默开关适合测试环境批量压制告警同时unhonouredOptions()依然可被代码查询即可以静音但不能假装没发生。在构造器中接入账本的推荐写法源码注释中的示例是if (config.sandbox ! undefined) notYetHonoured(Agent, sandbox);这样任何被接受但不生效的选项都会在运行时自我声明而不是静默消失。三、检查器与棘轮python -m praisonai._dev.parity.behaviourPython 侧的行为检查器位于 src/praisonai/praisonai/_dev/parity/behaviour.py它读取上述 TypeScript 账本、扫描src/praisonai-ts/src下的全部.ts源码然后生成BEHAVIOUR_PARITY.md与behaviour-parity.json两份报告。核心命令# 重新生成报告Markdown JSON python -m praisonai._dev.parity.behaviour --write # 校验报告是否过期 / 总数是否上升 python -m praisonai._dev.parity.behaviour --check命令支持四个参数参数作用--write重新生成BEHAVIOUR_PARITY.md与behaviour-parity.json--check若报告过期或总数上升则失败退出--allow-growth允许--write提升已提交的总数须在 PR 中说明理由总数下降永远不需要该标志--repo-root指定仓库根目录默认自动探测机制上它是一把棘轮ratchet已提交报告behaviour-parity.json中的total是下限当前总数只许下降、不许上升。--write同样强制执行该棘轮——因为它在每次推送到 main 时都会运行并自动提交若没有这道闸数量上升就会靠写进去而不是靠论证进入主干。--check的失败信息会明确指出某选项被接受但被忽略能通过名称与签名两道关卡因此这是唯一能看到它的检查。检查器的防作弊设计账本解析并非简单的正则逐行匹配而是结构化扫描其注释记录了两次踩坑教训表面surface不能被解析丢失冒充进度若某个Surface: [...]条目因解析器不认识而漏读总数会下降看起来像进步、还能被--write固化。因此扫描器按大括号深度逐字符解析对象字面量并用两个独立手段交叉校验_verify_parse用另一套独立正则_KEY_RE重新读出账本声明的所有表面与扫描结果比对不一致即报错对 TypeScript 源码中每个unhonouredFor(X)调用点做反向核对——账本仍声明 X、但解析没看到它就判定为解析失败绝不当作关闭。键的引用风格不设限JavaScript 对象键既可以是带引号字符串也可以是裸标识符Handoff: [...]与Handoff: [...]都合法引号也允许 三种。解析器全部兼容否则某种风格会让表面悄悄掉出计数再次伪装成进度。注释剥离_strip_comments在保留所有偏移量与字符串的前提下清空//与/* */注释被注释掉的条目不得计入真实条目也不得因注释紧邻而丢失。拒绝零选项误报如果账本结构变化导致一个表面都没解析出来直接抛出LedgerError——绝不允许在解析器失配时报出无事可做。此外凡是在UNHONOURED_OPTIONS顶层出现非Surface: [...]形式的记号、表面重复声明、选项名不符合[A-Za-z_][A-Za-z0-9_]*规范与字符串总数不一致等都会引发LedgerError把潜在的错误消灭在生成阶段。四、当前工作队列10 个未生效选项报告摘要显示当前账本共登记10 个尚未生效的选项SurfaceOptions not yet acted onAgentTeam.__init__6Task.__init__4Total10另加17 个部分生效选项见第五节。每个账本条目就是一个工作单元实现它 → 从账本删除 → 补一条证明该选项确实改变代码行为的测试 → 重新生成报告。4.1AgentTeam.__init__6 项knowledge、guardrails、web、reflection、caching、learn这 6 个选项在 AgentTeam 构造器中通过 team.ts 的统一循环上报const accepted: Array[string, unknown] unhonouredFor(AgentTeam.__init__) .filter((name) !HONOURED_HERE.has(name)) .map((name) [name, (config as unknown as Recordstring, unknown)[name]] as [string, unknown]); for (const [name, value] of accepted) { if (value ! undefined value ! false value ! null) { notYetHonoured(AgentTeam, name, TEAM_OPTION_NOTES[name]); } }其中HONOURED_HERE集合把已在团队层面落地的选项autonomy、toolsRunOn、memory、context、hooks、planning、execution、runOn、managerLlm从告警循环中排除避免对已实现的行为误报。值得注意的源码细节TEAM_OPTION_NOTESteam.ts揭示了这 6 项未生效并非 TypeScript 侧的单方面落后——Python 参考实现同样不在团队级别应用它们其构造器会记录类似AgentTeam received [...] but does not yet apply them at the team level; pass these to individual Agent(...) instances instead的提示。也就是说在这 6 个选项上实现团队级行为反而会偏离参考实现正确的替代方案是把这些能力传给单个Agent(...)实例例如knowledge的提示明确写道Python does not apply it at the team level either; pass knowledge to individual Agent(...) instances.。这一结论与 team-options.ts 中团队级execution/hooks/context已实现解析器的现状互为印证说明团队表面的对齐工作是从这些选项开始的。4.2Task.__init__4 项autonomy、web、reflection、planningTask 侧的做法是把账本直接当作引擎级选项列表。在 types.ts 中/** Options Task accepts for parity but whose behaviour lives in the execution engine, not in Task. */ const ENGINE_LEVEL_OPTIONS unhonouredFor(Task.__init__) as ReadonlyArraykeyof TaskConfig;构造器在 types.ts 中遍历该列表凡是被调用方传入的选项就上报notYetHonoured(Task, option)。注释点明了分工逻辑这些选项的行为归属地是执行引擎team-runner 等而非 Task 对象本身因此 Task 暂存它们、由引擎消费——decision就是一个已落地的例子runner 读取它驱动路由表。此外taskType与字符串形式的guardrails需要 LLM 评判器也会被单独上报属于部分生效的范畴。五、Partial 表17 个部分生效的选项部分生效partial的判定依据是源码中notYetHonoured(Surface, Option, why)带三个参数的调用——选项对某些输入有效、对其余输入则自我声明。检查器用正则_PARTIAL_RE从全部 TS 源码中收集这些调用点behaviour.py并把它们与账本分开统计因为并非完全缺失。当前 17 个分布如下SurfaceOptionDeclared inAgentcontextsrc/praisonai-ts/src/agent/simple.tsAgentguardrailssrc/praisonai-ts/src/agent/simple.tsAgentknowledgesrc/praisonai-ts/src/agent/simple.tsAgentmemorysrc/praisonai-ts/src/agent/simple.tsAgentreasoningEffortsrc/praisonai-ts/src/agent/simple.tsAgenttoolConfigsrc/praisonai-ts/src/agent/simple.tsAgentwebsrc/praisonai-ts/src/agent/simple.tsAgent.chatattachmentssrc/praisonai-ts/src/agent/simple.tsAgent.chatoutputPydanticsrc/praisonai-ts/src/agent/simple.tsAgent.chatseedsrc/praisonai-ts/src/agent/simple.tsAgentTeamcontextsrc/praisonai-ts/src/agent/team-options.tsAgentTeamexecutionsrc/praisonai-ts/src/agent/team-options.tsAgentTeamhookssrc/praisonai-ts/src/agent/team-options.tsAgentTeammemorysrc/praisonai-ts/src/agent/team-memory.tsAgentTeamplanningsrc/praisonai-ts/src/agent/team-planning.tsChromaMemoryragDbPathsrc/praisonai-ts/src/memory/adapters.tsTaskguardrailssrc/praisonai-ts/src/agent/types.ts几个典型的部分生效实现展示告警携带的可操作信息Agent的websimple.tstavily、exa、perplexity、parallel四个提供商可工作未知提供商则告警Unknown web search provider ... (available: tavily, exa, perplexity, parallel).Agent的memorysimple.tstrue、MemoryConfig、文件路径、Memory 实例均可用未识别的预设字符串则提示pass true, a MemoryConfig, a file path or a Memory instance.Agent.chat的outputPydanticsimple.tsJSON Schema、带toJSONSchema()的对象、zod schema 都能转换其余类型告警后忽略AgentTeam的executionteam-options.ts预设fast/balanced/thorough/unlimited与[preset, overrides]合并均可用未识别的预设名会列出全部合法取值ChromaMemory的ragDbPathadapters.tsTypeScript 的 Chroma 客户端是 HTTP-only因此该参数告警并建议改用host/port/path配置。可以看到partial 与完全未实现的差异在于前者主路径已可用仅边界输入被显式拒绝并给出替代方案因此从账本中单列统计。六、关闭一个选项的标准工作流报告把每个账本条目明确定义为一个工作单元标准流程四步实现行为让选项真正改变代码行为例如把AgentTeam.knowledge接到成员 Agent 的 KnowledgeBase 上删除账本条目从 parity-notice.ts 的UNHONOURED_OPTIONS中移除该选项名补测试证明新增一条测试证明有该选项时行为改变、无该选项时行为不变对照组思想因为账本是手写的删除本身就是一句已实现的声明必须用测试背书重新生成运行python -m praisonai._dev.parity.behaviour --write更新 Markdown 与 JSON 报告提交后总数下降即被棘轮认可。--write在检测到本次变更关闭了选项时会打印claimed closed by this change (N): Surface.option, ...并附上固定提醒本工具无法验证这一点账本为手写选项名无论如何都已出现在源码与测试中。每一项都需要一条证明选项改变代码行为的测试。——把删除这个动作的验证责任明确交给评审者与测试而不是假装检查器能自动确认。七、诚实的边界检查器不能看见的东西行为对齐机制对自身能力边界保持高度自觉behaviour.py 记录了三种曾被评估的自动验证删除候选方案及其测量结果针对当时 48 个条目选项在 src/ 中除 parity-notice.ts 外被引用0/48 会触发——签名关卡本就要求参数存在这条无法失败某个测试提及选项名0/48 会触发——同样必然通过某个不 import parity-notice 的测试提及选项名7/48 会触发——虽然能失败但其余 41 个只需在测试树任意位置出现裸标识符即可蒙混过关例如Task.web会被tools/registry.test.ts证明、AgentTeam.autonomy会被某个Agent.autonomy的测试证明。若采用等于为 85% 的删除开了绿灯还披着已验证的外衣一条注释就能满足它。结论是不加自动护栏数字保持诚实的自报。--write与--check打印本次变更声称关闭了什么交由评审者对照测试核查而不是假装验证。这份克制恰恰是这套机制的可靠性所在——它把无法机械证明的部分显式地暴露出来而不是用看似严谨的规则掩盖它。八、实践要点小结运行时可见性任何被接受但未生效的选项都会在传入时打印一次[praisonai] ... not yet honoured in TypeScript警告测试环境可用PRAISONAI_PARITY_SILENT1静音代码中仍可通过unhonouredOptions()查询治理纪律总数是棘轮只降不升需要上升必须--allow-growth并在 PR 中说明理由判断标准能通过名称与签名两层检查的选项唯一能拦住被接受即被忽略的就是行为层——因此每次新增 Python 对齐参数时要么接上实现要么登记入账并让它自我声明与 Python 的语义一致性AgentTeam的 6 个未生效选项在 Python 团队级别同样不生效正确做法是把这些能力下沉到单个Agent实例Task的 4 个选项则属于行为归属引擎Task 只负责暂存与上报。行为对齐不是简单的 TODO 列表而是一套把沉默缺陷转化为可见、可量化、只降不升的工程机制。理解BEHAVIOUR_PARITY.md及其背后的parity-notice.ts账本与behaviour.py检查器你就能在向 TypeScript SDK 新增 Python 对齐参数时既保证签名不缺也保证行为不空。【免费下载链接】PraisonAIPraisonAI — Hire a 24/7 AI Workforce. Stop writing boilerplate and start shipping autonomous self-improving agents that research, plan, code, and execute tasks. Deployed in 5 lines of code with built-in memory, RAG, and support for 100 LLMs.项目地址: https://gitcode.com/GitHub_Trending/pr/PraisonAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考