Agent Zero 错误格式化扩展点error_format深度解析异常脱敏与安全日志的源码实现【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero导读本文围绕 Agent Zero 后端内置扩展点error_formatextensions/python/error_format/AGENTS.md展开系统讲解 Agent Zero 如何在异常展示与落盘之前统一完成错误格式化与密钥脱敏。读者将掌握该扩展点的职责边界、_10_mask_errors.py掩码实现、RepairableException异常处理调用链、SecretsManager.mask_values的脱敏规则以及如何在自己的 Agent 中扩展或验证该行为避免原始令牌、凭据与隐藏提示泄露到用户界面或日志中。一、扩展点定位错误信息暴露前的最后一道闸门在 Agent Zero 中error_format是 extensions/python/ 下按目录命名的内置后端扩展点之一与agent_init、hist_add_before、reasoning_stream_chunk、response_stream_chunk等并列属于生命周期扩展lifecycle extensions。其核心定位在扩展点文档的 Purpose 一节中写得很明确Own backend error formatting and masking before errors are shown or logged.即在错误被展示打印到控制台、写入历史或记录写入日志之前由该扩展点统一接管错误数据的格式化和掩码处理。这意味着它是安全防线的一部分——所有经由该扩展点输出的错误信息都必须经过脱敏审查。该扩展点的正式登记可见两处extensions/python/AGENTS.md 的 Child DOX Index 中登记为 Error formatting and masking behaviorskills/a0-development/references/extensions.md 的 Current Built-In Python Hook Directories 列表中列出error_format为目录型内置钩子。二、扩展点契约五个维度的职责边界extensions/python/error_format/AGENTS.md 以 DOXDomain of eXpertise格式定义了该扩展点的完整契约逐节解读如下2.1 Purpose目的该扩展点拥有后端错误格式化与掩码的所有权工作窗口是错误被展示或记录之前。它不是一个只读观察点而是可以对错误数据进行实际修改的环节。2.2 Ownership所有权Ordered Python files own mutation of error-format data passed by the hook.这句话包含两个关键信息ordered有序目录内的 Python 文件按照确定性的文件名顺序加载执行。这正是_10_mask_errors.py以_10_数字前缀命名的原因——参照 extensions/python/AGENTS.md 的 Ownership 约定Python files inside an extension point are loaded in deterministic filename order且Preserve numeric prefixes when ordering affects prompt construction, stream masking, persistence, or cleanup。数字前缀越小越先执行_10_表明掩码逻辑位于该扩展点流水线的最前端。mutation可变操作扩展负责修改钩子传入的 error-format 数据即msg字典而非只读。2.3 Local Contracts本地契约保留密钥掩码能力与对用户安全的错误消息绝不暴露原始令牌raw tokens、凭据credentials、隐藏提示hidden prompts或私有载荷private payloads。这是整个扩展点的安全红线与 extensions/python/AGENTS.md 中 Do not log unmasked secrets, raw hidden prompt sections, or private user data 的全局约束一致。2.4 Work Guidance工作指引Keep masking rules conservative and synchronized with tool/model error surfaces.掩码规则要保持保守宁可多掩码不可漏掩码并且要与工具tool和模型model的错误表面保持同步——即当底层工具或模型新增了可能携带敏感信息的错误输出时掩码规则需要同步跟进。2.5 Verification验证Test or inspect representative masked and unmasked error paths after changes.修改后必须测试或检查有代表性的已掩码与未掩码错误路径确保两类路径行为都符合预期。三、源码实现_10_mask_errors.py逐行拆解该扩展点唯一的实现文件是 extensions/python/error_format/_10_mask_errors.py完整逻辑非常精简from helpers.extension import Extension from helpers.secrets import get_secrets_manager class MaskErrorSecrets(Extension): async def execute(self, **kwargs): if not self.agent: return # Get error data from kwargs msg kwargs.get(msg) if not msg: return secrets_mgr get_secrets_manager(self.agent.context) # Mask the error message if message in msg: msg[message] secrets_mgr.mask_values(msg[message])关键点继承Extension基类Extension定义于 helpers/extension.py其构造函数接收agent与kwargs并要求子类实现execute方法抽象方法可返回同步None或可等待对象。守卫条件if not self.agent与if not msg两个早退守卫保证无 Agent 上下文或未传入错误数据时不产生副作用。数据契约钩子以msg关键字参数传入一个字典扩展通过kwargs.get(msg)取出。从调用点看msg的标准形态是{message: 格式化后的错误文本}。就地修改msg[message] secrets_mgr.mask_values(msg[message])对错误文本原地脱敏这正是 Ownership 中 mutation of error-format data 的具体落点——调用方持有的同一个msg字典会被修改。值得注意的是execute是async def因此该扩展在call_extensions_async异步流水线中执行。四、调用链还原RepairableException 如何流入 error_format要理解error_format何时被触发需要追踪它的唯一调用点 extensions/python/_functions/agent/Agent/handle_exception/end/_50_handle_repairable_exception.py。这段代码位于extensible隐式扩展点_functions/agent/Agent/handle_exception/end/下关于extensible装饰器与_functions/module/qualname/start|end/目录布局的机制见 helpers/extension.py 与 skills/a0-development/references/extensions.md。其核心流程if isinstance(data[exception], RepairableException): msg {message: errors.format_error(data[exception])} await extension.call_extensions_async(error_format, agentself.agent, msgmsg) wmsg self.agent.hist_add_warning(msg[message]) PrintStyle(font_colorred, paddingTrue).print(msg[message]) self.agent.context.log.log(typewarning, contentmsg[message], idwmsg.id) data[exception] None调用链可概括为Agent 主循环抛出异常异常被包装进data[exception]handle_exception/end钩子判断异常是否为RepairableException定义于 helpers/errors.py语义为可以上抛给 LLM 进行自我修复的错误类型通过errors.format_error(data[exception])将异常格式化为人类可读的堆栈文本构造msg {message: ...}触发error_format扩展点把msg交给_10_mask_errors.py脱敏脱敏后的msg[message]被写入历史警告hist_add_warning、红色打印到控制台、并以 warning 级别写入日志最后清空data[exception]表示异常已被处理。从这段代码可以清晰地看到契约设计错误文本在写入历史、控制台与日志三个输出面之前都经过了error_format的统一脱敏。这也是文档中 before errors are shown or logged 的实证。4.1 错误文本的格式化细节errors.format_errormsg[message]的原始文本由 helpers/errors.py 的format_error生成理解它有助于判断脱敏的输入形态基于traceback.format_exception还原完整堆栈默认保留开头 20 帧start_entries20与结尾 15 帧end_entries15中间部分用 N stack lines skipped 占位避免超长堆栈刷屏提取形如模块路径.Error: 消息的最终错误行并可选择置于顶部error_message_positiontop默认、底部或省略。堆栈文本往往包含文件路径、环境变量、甚至是拼接到命令或请求中的敏感值这正是必须在其后追加掩码步骤的原因。五、脱敏底层SecretsManager.mask_values 与密钥来源_10_mask_errors.py调用的是 helpers/secrets.py 中的get_secrets_manager(self.agent.context)与mask_values。这两者决定了哪些值会被掩码、以什么形式掩码。5.1 密钥来源多级密钥合并get_secrets_manager会按当前上下文合并三类密钥文件全局默认密钥文件usr/secrets.env常量DEFAULT_SECRETS_FILE运行时凭据文件usr/.env通过dotenv.get_dotenv_file_path()获取其中只纳入API_KEY_*前缀键与运行时代理凭据键AUTH_LOGIN、AUTH_PASSWORD、RFC_PASSWORD、ROOT_PASSWORD见_RUNTIME_CREDENTIAL_KEYS——普通配置项如ANONYMIZED_TELEMETRY不会被当作密钥若当前处于某个项目上下文则追加该项目元数据目录下的secrets.env。5.2 mask_values 的掩码规则SecretsManager.mask_values(text, min_length4, placeholder§§secret({key}))的核心逻辑从已加载密钥中取出所有key - value对按值长度降序排序后逐一执行text.replace(value, alias)——先替换长值避免短值覆盖长值导致的错位只有值去除首尾空白后长度≥ min_length默认 4的密钥才参与替换避免把过短的通用字符串如a误伤成掩码替换结果为占位符格式§§secret(KEY)密钥名大写例如§§secret(PROJECT_SECRET)、§§secret(API_KEY_OPENAI)。该行为有直接的测试佐证tests/test_secrets.py 中的test_agent_secret_manager_masks_runtime_credentials_only验证了manager.mask_values( project-value; keyllm-secret-value; avoid falsely accusing a utility ) ( §§secret(PROJECT_SECRET); key§§secret(API_KEY_OPENAI); avoid falsely accusing a utility )即usr/secrets.env中的PROJECT_SECRET与usr/.env中的API_KEY_OPENAI都被替换为占位符而普通文本保持不变同时ANONYMIZED_TELEMETRY这类非密钥配置不会进入提示词中的密钥清单。5.3 补充防线StreamingSecretsFilter除mask_values之外helpers/secrets.py 还提供StreamingSecretsFilter用于流式输出场景的逐块脱敏缓存当前缓冲区中能匹配任一密钥前缀的最长后缀min_trigger最小触发长度为 3避免密钥被分块切割导致部分泄露先整体替换完整值再判断尾部是否为可疑前缀并暂存finalize()时若仍残留未解析的密钥前缀统一以***掩码。这解释了扩展点文档 Work Guidance 中 synchronized with tool/model error surfaces 的工程背景模型流式输出response_stream_chunk、reasoning_stream_chunk与错误文本error_format分属不同扩展点但共用同一套SecretsManager掩码基础从而保证掩码规则在整个 Agent Zero 输出面上保持一致。六、扩展加载机制有序执行、缓存与热更新error_format之所以能有序执行依赖 helpers/extension.py 的扩展加载器按目录聚合_get_extension_classes(extension_point, agent)通过subagents.get_paths(agent, extensions/python, extension_point)在当前 Agent 的所有路径中查找extensions/python/error_format/目录。文件名去重与排序多个目录下的同名模块以首次出现者为覆盖override最终按_get_file_from_module即文件名排序——这正是_10_前缀能决定执行顺序的原因。缓存扩展类结果缓存在_CLASSES_CACHE_AREA单目录类列表缓存在_EXTENSIONS_CACHE_AREA避免热路径重复扫描文件系统。Watchdog 热更新register_extensions_watchdogs对内置extensions/、用户级usr/extensions/、项目级与 Agent 级扩展目录注册文件监视文件变更即清空扩展缓存实现无重启生效。因此如果要为error_format增加自定义掩码规则只需在对应 Agent 路径的extensions/python/error_format/目录下新增以数字前缀命名的Extension子类文件例如_20_my_extra_mask.py在_10_之后执行无需修改框架代码。七、验证与质量保障根据扩展点文档的 Verification 要求变更后需要检查两类代表性路径已掩码路径构造包含真实密钥值如usr/secrets.env中的值的RepairableException确认经error_format处理后写入历史、控制台和日志的文本中密钥已被替换为§§secret(KEY)占位符未掩码路径确认普通错误信息不含密钥不会被误伤改写错误文本保持完整可读。现有测试基础设施中tests/test_secrets.py 覆盖了mask_values与流式过滤器的掩码语义可作为扩展掩码规则时对齐行为的参照。涉及错误处理生命周期handle_exception相关的改动还应参照 extensions/python/AGENTS.md 的建议运行针对性测试与启动冒烟检查。八、总结与最佳实践error_format扩展点虽小却是 Agent Zero 安全输出链路的关键一环其设计要点可总结为单一出口所有面向用户/日志的错误文本统一流经error_format避免各模块各自格式化导致的脱敏遗漏前置掩码_10_数字前缀保证掩码是该扩展点流水线的第一步后续所有消费方历史、控制台、日志拿到的都是已脱敏文本保守原则掩码规则宁严勿松且须随工具/模型错误表面的演进同步更新契约驱动Purpose / Ownership / Local Contracts / Work Guidance / Verification 五段式 DOX 明确了扩展的所有权、修改权、安全红线与验收标准为二次开发提供了清晰的边界。对于希望扩展错误处理的开发者建议遵循以下路径阅读 extensions/python/error_format/AGENTS.md 理解契约 → 参照 extensions/python/error_format/_10_mask_errors.py 的Extension写法新增有序扩展文件 → 对照 helpers/secrets.py 的mask_values与 tests/test_secrets.py 的测试用例验证脱敏效果 → 最后分别检查已掩码与未掩码两条错误路径确保安全性与可读性兼得。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Agent Zero 错误格式化扩展点（error_format）深度解析：异常脱敏与安全日志的源码实现
Agent Zero 错误格式化扩展点error_format深度解析异常脱敏与安全日志的源码实现【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero导读本文围绕 Agent Zero 后端内置扩展点error_formatextensions/python/error_format/AGENTS.md展开系统讲解 Agent Zero 如何在异常展示与落盘之前统一完成错误格式化与密钥脱敏。读者将掌握该扩展点的职责边界、_10_mask_errors.py掩码实现、RepairableException异常处理调用链、SecretsManager.mask_values的脱敏规则以及如何在自己的 Agent 中扩展或验证该行为避免原始令牌、凭据与隐藏提示泄露到用户界面或日志中。一、扩展点定位错误信息暴露前的最后一道闸门在 Agent Zero 中error_format是 extensions/python/ 下按目录命名的内置后端扩展点之一与agent_init、hist_add_before、reasoning_stream_chunk、response_stream_chunk等并列属于生命周期扩展lifecycle extensions。其核心定位在扩展点文档的 Purpose 一节中写得很明确Own backend error formatting and masking before errors are shown or logged.即在错误被展示打印到控制台、写入历史或记录写入日志之前由该扩展点统一接管错误数据的格式化和掩码处理。这意味着它是安全防线的一部分——所有经由该扩展点输出的错误信息都必须经过脱敏审查。该扩展点的正式登记可见两处extensions/python/AGENTS.md 的 Child DOX Index 中登记为 Error formatting and masking behaviorskills/a0-development/references/extensions.md 的 Current Built-In Python Hook Directories 列表中列出error_format为目录型内置钩子。二、扩展点契约五个维度的职责边界extensions/python/error_format/AGENTS.md 以 DOXDomain of eXpertise格式定义了该扩展点的完整契约逐节解读如下2.1 Purpose目的该扩展点拥有后端错误格式化与掩码的所有权工作窗口是错误被展示或记录之前。它不是一个只读观察点而是可以对错误数据进行实际修改的环节。2.2 Ownership所有权Ordered Python files own mutation of error-format data passed by the hook.这句话包含两个关键信息ordered有序目录内的 Python 文件按照确定性的文件名顺序加载执行。这正是_10_mask_errors.py以_10_数字前缀命名的原因——参照 extensions/python/AGENTS.md 的 Ownership 约定Python files inside an extension point are loaded in deterministic filename order且Preserve numeric prefixes when ordering affects prompt construction, stream masking, persistence, or cleanup。数字前缀越小越先执行_10_表明掩码逻辑位于该扩展点流水线的最前端。mutation可变操作扩展负责修改钩子传入的 error-format 数据即msg字典而非只读。2.3 Local Contracts本地契约保留密钥掩码能力与对用户安全的错误消息绝不暴露原始令牌raw tokens、凭据credentials、隐藏提示hidden prompts或私有载荷private payloads。这是整个扩展点的安全红线与 extensions/python/AGENTS.md 中 Do not log unmasked secrets, raw hidden prompt sections, or private user data 的全局约束一致。2.4 Work Guidance工作指引Keep masking rules conservative and synchronized with tool/model error surfaces.掩码规则要保持保守宁可多掩码不可漏掩码并且要与工具tool和模型model的错误表面保持同步——即当底层工具或模型新增了可能携带敏感信息的错误输出时掩码规则需要同步跟进。2.5 Verification验证Test or inspect representative masked and unmasked error paths after changes.修改后必须测试或检查有代表性的已掩码与未掩码错误路径确保两类路径行为都符合预期。三、源码实现_10_mask_errors.py逐行拆解该扩展点唯一的实现文件是 extensions/python/error_format/_10_mask_errors.py完整逻辑非常精简from helpers.extension import Extension from helpers.secrets import get_secrets_manager class MaskErrorSecrets(Extension): async def execute(self, **kwargs): if not self.agent: return # Get error data from kwargs msg kwargs.get(msg) if not msg: return secrets_mgr get_secrets_manager(self.agent.context) # Mask the error message if message in msg: msg[message] secrets_mgr.mask_values(msg[message])关键点继承Extension基类Extension定义于 helpers/extension.py其构造函数接收agent与kwargs并要求子类实现execute方法抽象方法可返回同步None或可等待对象。守卫条件if not self.agent与if not msg两个早退守卫保证无 Agent 上下文或未传入错误数据时不产生副作用。数据契约钩子以msg关键字参数传入一个字典扩展通过kwargs.get(msg)取出。从调用点看msg的标准形态是{message: 格式化后的错误文本}。就地修改msg[message] secrets_mgr.mask_values(msg[message])对错误文本原地脱敏这正是 Ownership 中 mutation of error-format data 的具体落点——调用方持有的同一个msg字典会被修改。值得注意的是execute是async def因此该扩展在call_extensions_async异步流水线中执行。四、调用链还原RepairableException 如何流入 error_format要理解error_format何时被触发需要追踪它的唯一调用点 extensions/python/_functions/agent/Agent/handle_exception/end/_50_handle_repairable_exception.py。这段代码位于extensible隐式扩展点_functions/agent/Agent/handle_exception/end/下关于extensible装饰器与_functions/module/qualname/start|end/目录布局的机制见 helpers/extension.py 与 skills/a0-development/references/extensions.md。其核心流程if isinstance(data[exception], RepairableException): msg {message: errors.format_error(data[exception])} await extension.call_extensions_async(error_format, agentself.agent, msgmsg) wmsg self.agent.hist_add_warning(msg[message]) PrintStyle(font_colorred, paddingTrue).print(msg[message]) self.agent.context.log.log(typewarning, contentmsg[message], idwmsg.id) data[exception] None调用链可概括为Agent 主循环抛出异常异常被包装进data[exception]handle_exception/end钩子判断异常是否为RepairableException定义于 helpers/errors.py语义为可以上抛给 LLM 进行自我修复的错误类型通过errors.format_error(data[exception])将异常格式化为人类可读的堆栈文本构造msg {message: ...}触发error_format扩展点把msg交给_10_mask_errors.py脱敏脱敏后的msg[message]被写入历史警告hist_add_warning、红色打印到控制台、并以 warning 级别写入日志最后清空data[exception]表示异常已被处理。从这段代码可以清晰地看到契约设计错误文本在写入历史、控制台与日志三个输出面之前都经过了error_format的统一脱敏。这也是文档中 before errors are shown or logged 的实证。4.1 错误文本的格式化细节errors.format_errormsg[message]的原始文本由 helpers/errors.py 的format_error生成理解它有助于判断脱敏的输入形态基于traceback.format_exception还原完整堆栈默认保留开头 20 帧start_entries20与结尾 15 帧end_entries15中间部分用 N stack lines skipped 占位避免超长堆栈刷屏提取形如模块路径.Error: 消息的最终错误行并可选择置于顶部error_message_positiontop默认、底部或省略。堆栈文本往往包含文件路径、环境变量、甚至是拼接到命令或请求中的敏感值这正是必须在其后追加掩码步骤的原因。五、脱敏底层SecretsManager.mask_values 与密钥来源_10_mask_errors.py调用的是 helpers/secrets.py 中的get_secrets_manager(self.agent.context)与mask_values。这两者决定了哪些值会被掩码、以什么形式掩码。5.1 密钥来源多级密钥合并get_secrets_manager会按当前上下文合并三类密钥文件全局默认密钥文件usr/secrets.env常量DEFAULT_SECRETS_FILE运行时凭据文件usr/.env通过dotenv.get_dotenv_file_path()获取其中只纳入API_KEY_*前缀键与运行时代理凭据键AUTH_LOGIN、AUTH_PASSWORD、RFC_PASSWORD、ROOT_PASSWORD见_RUNTIME_CREDENTIAL_KEYS——普通配置项如ANONYMIZED_TELEMETRY不会被当作密钥若当前处于某个项目上下文则追加该项目元数据目录下的secrets.env。5.2 mask_values 的掩码规则SecretsManager.mask_values(text, min_length4, placeholder§§secret({key}))的核心逻辑从已加载密钥中取出所有key - value对按值长度降序排序后逐一执行text.replace(value, alias)——先替换长值避免短值覆盖长值导致的错位只有值去除首尾空白后长度≥ min_length默认 4的密钥才参与替换避免把过短的通用字符串如a误伤成掩码替换结果为占位符格式§§secret(KEY)密钥名大写例如§§secret(PROJECT_SECRET)、§§secret(API_KEY_OPENAI)。该行为有直接的测试佐证tests/test_secrets.py 中的test_agent_secret_manager_masks_runtime_credentials_only验证了manager.mask_values( project-value; keyllm-secret-value; avoid falsely accusing a utility ) ( §§secret(PROJECT_SECRET); key§§secret(API_KEY_OPENAI); avoid falsely accusing a utility )即usr/secrets.env中的PROJECT_SECRET与usr/.env中的API_KEY_OPENAI都被替换为占位符而普通文本保持不变同时ANONYMIZED_TELEMETRY这类非密钥配置不会进入提示词中的密钥清单。5.3 补充防线StreamingSecretsFilter除mask_values之外helpers/secrets.py 还提供StreamingSecretsFilter用于流式输出场景的逐块脱敏缓存当前缓冲区中能匹配任一密钥前缀的最长后缀min_trigger最小触发长度为 3避免密钥被分块切割导致部分泄露先整体替换完整值再判断尾部是否为可疑前缀并暂存finalize()时若仍残留未解析的密钥前缀统一以***掩码。这解释了扩展点文档 Work Guidance 中 synchronized with tool/model error surfaces 的工程背景模型流式输出response_stream_chunk、reasoning_stream_chunk与错误文本error_format分属不同扩展点但共用同一套SecretsManager掩码基础从而保证掩码规则在整个 Agent Zero 输出面上保持一致。六、扩展加载机制有序执行、缓存与热更新error_format之所以能有序执行依赖 helpers/extension.py 的扩展加载器按目录聚合_get_extension_classes(extension_point, agent)通过subagents.get_paths(agent, extensions/python, extension_point)在当前 Agent 的所有路径中查找extensions/python/error_format/目录。文件名去重与排序多个目录下的同名模块以首次出现者为覆盖override最终按_get_file_from_module即文件名排序——这正是_10_前缀能决定执行顺序的原因。缓存扩展类结果缓存在_CLASSES_CACHE_AREA单目录类列表缓存在_EXTENSIONS_CACHE_AREA避免热路径重复扫描文件系统。Watchdog 热更新register_extensions_watchdogs对内置extensions/、用户级usr/extensions/、项目级与 Agent 级扩展目录注册文件监视文件变更即清空扩展缓存实现无重启生效。因此如果要为error_format增加自定义掩码规则只需在对应 Agent 路径的extensions/python/error_format/目录下新增以数字前缀命名的Extension子类文件例如_20_my_extra_mask.py在_10_之后执行无需修改框架代码。七、验证与质量保障根据扩展点文档的 Verification 要求变更后需要检查两类代表性路径已掩码路径构造包含真实密钥值如usr/secrets.env中的值的RepairableException确认经error_format处理后写入历史、控制台和日志的文本中密钥已被替换为§§secret(KEY)占位符未掩码路径确认普通错误信息不含密钥不会被误伤改写错误文本保持完整可读。现有测试基础设施中tests/test_secrets.py 覆盖了mask_values与流式过滤器的掩码语义可作为扩展掩码规则时对齐行为的参照。涉及错误处理生命周期handle_exception相关的改动还应参照 extensions/python/AGENTS.md 的建议运行针对性测试与启动冒烟检查。八、总结与最佳实践error_format扩展点虽小却是 Agent Zero 安全输出链路的关键一环其设计要点可总结为单一出口所有面向用户/日志的错误文本统一流经error_format避免各模块各自格式化导致的脱敏遗漏前置掩码_10_数字前缀保证掩码是该扩展点流水线的第一步后续所有消费方历史、控制台、日志拿到的都是已脱敏文本保守原则掩码规则宁严勿松且须随工具/模型错误表面的演进同步更新契约驱动Purpose / Ownership / Local Contracts / Work Guidance / Verification 五段式 DOX 明确了扩展的所有权、修改权、安全红线与验收标准为二次开发提供了清晰的边界。对于希望扩展错误处理的开发者建议遵循以下路径阅读 extensions/python/error_format/AGENTS.md 理解契约 → 参照 extensions/python/error_format/_10_mask_errors.py 的Extension写法新增有序扩展文件 → 对照 helpers/secrets.py 的mask_values与 tests/test_secrets.py 的测试用例验证脱敏效果 → 最后分别检查已掩码与未掩码两条错误路径确保安全性与可读性兼得。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
