后端前端协同办公即时通讯企业应用CRMAI Agent人工智能【免费下载链接】macroMacro is a unified workspace for teams: email, chat, docs, tasks, agents, calls, and CRM — -linked together with shared AI memory.项目地址https://gitcode.com/GitHub_Trending/macro3/macro点击查看免费下载本篇技术指南以crates/models_soupcrate 的模块说明为骨架拆解 Macro 统一活动流Soup在类型层面的设计一个SoupItem枚举如何同时承载文档、聊天、邮件线程、频道消息、CRM、通话、日历、Agent 会话与数据库行等多种实体以及它如何通过Identify、SortOn、EntityReference三个契约与分页、属性系统对接。读完后你可以独立完成“为 Soup 新增一种实体类型”的全链路改造并理解其序列化与排序边界。models_soup 的定位只做模型不做查询models_soup是 Soup feedHome/Recent、统一活动流的共享 API 模型层。它遵循一条非常清晰的职责边界拥有每种可被 Soup 展示的实体类型的响应模型以及统一条目类型。不拥有GraphQL resolver 与 feed 查询逻辑属于soup、graphql_soupSoup 过滤 DSL属于item_filters、soup_filter_projection。这一划分可以在 crate 根文件 lib.rs 中直接看到每个实体模块都带有一句 “models for Soup responses” 的文档注释并且整个 crate 开启了#![deny(missing_docs)]意味着任何新增的公开类型或字段都必须有文档注释否则编译失败。这是一个很实用的约束——它强制模型层始终可被外部前端、AI 工具、OpenAPI 生成器理解。模块清单如下模块对应实体item统一条目SoupItemdocument文档、任务、片段、技能、initiative 描述chat聊天project项目initiativeInitiative前端称为 projectemail_thread邮件线程及其附件、参与者、标签comms频道与频道消息线程call_record通话记录calendar_event日历事件crm_company/crm_contactCRM 公司与团队联系人foreign_entity外部系统实体映射agent_sessionAgent 会话database_row数据库行properties附着在条目上的属性SoupProperty依赖方向也在 Cargo.toml 中固定下来call、channels、crm、document_sub_type、doppleganger、email、macro_user_id、model、model-entity、model_owner、models_pagination、models_properties。这些依赖恰好对应它需要“读懂”的上游领域类型以及它需要实现的三个外部契约。统一条目 SoupItem一个枚举收口所有实体统一模型在 item.rs#[derive(Clone, Serialize, Deserialize, Debug)] #[serde(rename_all camelCase, tag tag, content data)] #[cfg_attr(feature schema, derive(utoipa::ToSchema))] pub enum SoupItemT () { Document(SoupDocumentT), Chat(SoupChatT), Project(SoupProjectT), Initiative(SoupInitiativeT), EmailThread(SoupEnrichedEmailThreadPreviewT), Channel(SoupChannel), ChannelThread(SoupChannelThread), Call(SoupCallRecordT), CalendarEvent(SoupCalendarEventT), CrmCompany(SoupCrmCompanyT), CrmContact(SoupCrmContactT), ForeignEntity(SoupForeignEntity), AgentSession(SoupAgentSessionT), DatabaseRow(SoupDatabaseRowT), }有三个设计点值得注意。第一tag/content的外部标记adjacently tagged序列化。JSON 形如{tag: document, data: { ... }}。这比内部标记#[serde(tag ...)]更适合这里因为多个变体的 payload 是结构体且包含flatten字段内部标记与#[serde(flatten)]组合时容易产生冲突。测试 item/test.rs 直接断言了value[data][model]这样的访问路径说明外层结构是稳定契约而非实现细节。第二泛型参数T ()是“扩展载荷”的挂载点。大部分变体都是SoupXxxT沉默的变体Channel、ChannelThread、ForeignEntity则没有扩展位——它们本身不支持附加属性。默认T ()让调用方在不做增强时零成本使用例如SoupItem()。第三ChannelThread携带的实体类型是ChannelMessage。在entity()的实现中可以看到这个细节SoupItem::ChannelThread(thread) { EntityType::ChannelMessage.with_entity_string(thread.id.to_string()) }也就是说“频道里的顶层消息线程”在实体系统中等价于一条 canonical 的 channel message这与 comms.rs 的文档注释一致该结构刻意镜像公开的 channel-message API 形状让 Soup 消费者可以用渲染频道时间线的同一套组件渲染线程根消息。四个必须实现的契约SoupItem之所以能直接进入分页管线是因为它在implT块中实现了四个对外契约。理解这四个方法就理解了整个模型层与外围系统的接口。1. entity()把条目映射到实体身份item.rs 中的entity()返回model_entity::Entitystatic逐变体地把 id 与EntityType组合起来。这是权限系统、活动流、缓存投影定位记录的统一入口——graphql_soup正是靠它来构造RecordKey见 graphql_soup/src/objects.rs。注意邮件线程映射的是email_thread.thread.id而不是外层包裹结构频道映射的是channel.channel.channel.id.0三层嵌套SoupChannel→ChannelWithParticipants→Channel→ChannelId这是flatten序列化的直接后果——payload 是扁平 JSON但内存表示是分层结构。2. updated_at()供 frecency 回退使用的“最近活动时间”updated_at()并不总是字段直读其中几个变体带有明确的语义修正// Calls intentionally lack updated_at; recency follows their lifecycle timestamps. SoupItem::Call(record) record.ended_at.unwrap_or(record.started_at), // Includes the fired-reminder timestamp so the frecency fallback // cursor agrees with the GREATEST-based recency sort. SoupItem::CalendarEvent(event) event .last_reminder_fired_at .map_or(event.updated_at, |fired| fired.max(event.updated_at)), SoupItem::CrmContact(contact) contact.last_interaction,这三处注释暴露了真实的工程约束内存侧的排序键必须与 SQL 侧的排序表达式严格一致否则游标分页会错页。日历事件的注释甚至直接点名了 SQL 中的GREATEST(updated_at, last_reminder_fired_at)CRM 联系人以last_interaction而非updated_at作为“最近”依据通话记录由于没有updated_at列退化为生命周期时间戳。3. cursor_timestamp()按排序方式取不同的时间值item.rs 中的cursor_timestamp(self, sort: SimpleSortMethod)是私有方法通过SortOn暴露出去。它按SimpleSortMethod定义于 models_pagination/src/sort.rs分支pub enum SimpleSortMethod { ViewedAt, UpdatedAt, CreatedAt, ViewedUpdated, }大量变体的模式是高度一致的ViewedAt取viewed_at.unwrap_or_default()UpdatedAt取updated_atCreatedAt取created_atViewedUpdated取viewed_at.unwrap_or(updated_at)。但存在若干刻意的例外它们是排查“排序结果奇怪”问题的第一现场邮件线程忽略排序方式永远使用thread.sort_ts。注释说明这是邮件 SQL 查询预先计算出的effective_ts游标偏移逻辑(effective_ts, id) (cursor_ts, cursor_id)依赖它。频道线程只有CreatedAt走created_at其余一律走effective_updated_at()其实现为latest_reply_at.unwrap_or(updated_at).max(updated_at)comms.rs——线程的新回复会让父消息浮到前面。数据库行从不被单独浏览ViewedAt返回DateTime::default()排到最后ViewedUpdated退化为updated_at。日历事件的ViewedAt返回默认时间因为事件没有 per-viewer 的浏览记录字段。这些“特殊分支”不是随意写的call_record/test.rs里的assert_call_recency就是这种一致性的守卫它对ViewedAt、UpdatedAt、ViewedUpdated三种排序都断言sort_on(item).last_val expected见 call_record/test.rs。4. Identify 与 SortOn接入键集分页implT Identify for SoupItemT { type Id Uuid; fn id(self) - Self::Id { /* 逐变体取主键 */ } } implT SortOnSimpleSortMethod for SoupItemT { fn sort_on(sort: SimpleSortMethod) - impl FnMut(Self) - models_pagination::CursorValSimpleSortMethod { move |v| models_pagination::CursorVal { sort_type: sort, last_val: v.cursor_timestamp(sort) } } }这两个 trait 定义在 models_pagination/src/cursor.rs。CursorValC的结构是{ sort_type, last_val }同文件 L84-L92因此游标本身是自描述的它既知道“按哪种时间排”也知道“上一页最后一条的时间值”。Identify提供 id 作为二级排序键保证时间戳相同时仍有确定性顺序。soupcrate 的分组逻辑直接复用了它grouping.rs 中let mut get_cursor_val SoupItem::sort_on(sort_method);然后对每个分组内的最后一条记录生成CursorWithValAndFilterUuid, SimpleSortMethod, EntityFilterAst并 Base64 编码为组级next_cursor同文件 L116-L147。这解释了为什么SoupItem的排序实现必须精确一处偏差会同时污染页级游标与组级游标。属性系统to_entity_reference 与 SoupPropertySoup 的条目可以带属性状态、优先级、标签等。模型层通过to_entity_reference()把条目翻译成models_properties::EntityReferencepub fn to_entity_reference(self) - OptionEntityReference { ... }关键点是返回Option并且有明确的空值语义item.rs返回NoneChannel、ChannelThread、CrmContact、ForeignEntity、AgentSession。AgentSession的空值理由写在注释里“Agent sessions have no properties entity type yet.”——这是尚未建模而非设计上不支持。文档的实体类型是动态的doc.entity_type()会根据sub_type返回Task或Document见下文。属性值本身的模型在 properties.rspub struct SoupProperty { pub id: Uuid, pub definition: PropertyDefinition, #[serde(skip_serializing_if Option::is_none)] pub value: OptionPropertyValue, }它的FromEntityPropertyWithDefinition实现刻意丢弃了options字段。注释给出了理由Soup 条目只需要“定义 当前值”可选项如 select 的候选项列表应在编辑 UI 需要时另行获取。这是一个典型的“列表页轻量化”取舍——避免每一行都携带全部属性元数据。在服务侧属性通过泛型扩展位注入soupcrate 定义了SoupPropertiesField { properties: VecSoupProperty }与类型别名SoupItemWithProperties SoupItemSoupPropertiesFieldsoup/src/domain/models.rs数据库层则直接map(SoupProperty::from)转换soup/src/outbound/pg_soup_repo.rs。map_extra 与 extra 扁平化扩展载荷的工作机制SoupItemT的泛型参数如何落到 JSON 上答案在map_extraitem.rspub fn map_extraU, F(self, f: F) - SoupItemU where F: FnOnce(T) - U它的实现是逐变体的结构体解构再重建——把每个字段逐一写出只把extra替换为f(extra)。这看起来啰嗦但换来了两个好处编译器会在新增字段时强制你更新此处不会静默丢失字段且不支持 extra 的变体Channel等会原样透传。配套的是各模型结构体上的#[serde(flatten)] pub extra: T。测试用例精确地刻画了这条链路#[test] fn raw_extra_serializes_without_fields() { let value serde_json::to_value(raw_chat()).unwrap(); assert!(value[data].get(extra).is_none()); assert!(value[data].get(properties).is_none()); } #[test] fn mapped_extra_is_flattened_into_the_item_data() { let item raw_chat().map_extra(|()| TestPropertiesField { properties: vec![priority.to_string()] }); let value serde_json::to_value(item).unwrap(); assert_eq!(value[data][properties], serde_json::json!([priority])); assert!(value[data].get(extra).is_none()); }注意第二处断言extra这个键名不会出现在 JSON 里扩展字段被平铺到data层级。这是flatten 具名结构体的必然结果也是前端可以直接data.properties取值的原因。SoupItem()时()不产生任何字段因此extra键与内部字段都不存在——序列化形状随泛型参数变化这一点在设计客户端类型时必须考虑。各实体模型的关键取舍文档与子类型类型安全的“任务属性”document.rs 用枚举把“子类型”和“该子类型才有的属性”绑在一起#[serde(tag type, rename_all snake_case)] pub enum SoupDocumentSubType { Task { is_completed: bool }, Snippet {}, Skill {}, InitiativeDescription {}, }注释点明动机Task变体才带is_completed从而在类型层面保证“任务属性只在文档是任务时存在”。from_db负责从数据库的两个独立列sub_type与is_completed合成领域枚举is_task_completed()则提供反向的、只对任务有意义的查询。SoupDocumentT里还有两个值得注意的字段语义document_version_id可能是document_instance_id或document_bom_id取决于文件类型sha只在 PDF 上存在DOCX 没有。这类“同一字段在不同文件类型下含义不同”的信息正是模型注释存在的价值——它无法由类型系统表达。entity_type()的映射规则L118-L136只有Task映射为EntityType::TaskSnippet、Skill、InitiativeDescription以及None全部映射为EntityType::Document。注释解释了原因“片段性/技能性只存在于sub_type中”实体系统不为此单开类型。这直接影响属性查询技能文档的属性查找会走Document实体类型。频道扁平化嵌套与 is_participant 的作用域comms.rs 是本 crate 中最“重”的模块它把channels领域的多个类型转换成 Soup 形状并提供了大量new_from_*转换函数。SoupChannel由两个flatten组成ChannelWithParticipants与LatestMessage再加上viewed_at、interacted_at两个 per-viewer 时间戳。LatestMessage同时携带latest_message含线程回复的最新消息与latest_non_thread_message最新顶层消息这是频道列表中“预览文本”与“话题流”两种展示需求并存的产物。is_participant的作用域被明确测试过comms/test.rs 断言它出现在条目顶层而不出现在data.channel内部因为“该标志描述的是请求用户而不是频道行本身”。同时它带有#[serde(default)]缺失时可以反序列化为false同文件 L38-L49保证向后兼容。sender_id的双轨设计也值得注意SoupChannelThread同时保留原始sender_id: String和结构化的sender: SoupMessageSender。后者通过ChannelSender::parse_from_str解析存储前缀区分User与Bot并在 bot 场景下填充name与avatar_url见from_storage_string与from_message_senderL469-L517。解析失败时退化为User类型并原样保留 id——一个不会让整条消息渲染失败的保守回退。邮件线程用 Doppleganger 镜像上游类型email_thread.rs大量使用doppleganger的Doppleganger/Mirror派生#[derive(Clone, Debug, Doppleganger, Serialize, Deserialize)] #[dg(backward email::domain::models::EmailThreadPreview)] pub struct SoupEmailThreadPreview { ... }这带来的直接好处是转换样板可以自动生成impl Fromemail::domain::models::EnrichedEmailThreadPreview for SoupEnrichedEmailThreadPreview() { fn from(preview: ...) - Self { Self { thread: SoupEmailThreadPreview::mirror(preview.thread), attachments: Vec::SoupAttachment::mirror(preview.attachments), participants: Vec::SoupContact::mirror(preview.participants), labels: Vec::SoupLabel::mirror(preview.labels), extra: (), } } }这里有一个容易误读的字段is_signal。注释特别澄清它与is_important的区别——is_signal是去规范化的email_threads.is_signal重要度分类也正是 Soup 的 Importance 过滤器所评估的标志is_important则是 Gmail 的 IMPORTANT 标签。两者同名近似语义完全不同写前端筛选逻辑时必须区分。另外sort_ts是邮件排序的专用字段与updated_at分离原因已在前文的cursor_timestamp部分说明。CRM团队归属与可见范围SoupCrmCompanyT携带team_id、hidden、email_sync以及按创建时间升序排列的domains首个为主域。name与description是从crm_domain_directory按主域解析出的展示信息可能为None——注释明确写出“unresolved”的情况提醒调用方不要假设一定有值。SoupCrmDomain注释说它“镜像 crm crate 的CrmDomain但提供前端可依赖的稳定 wire 形状”。这是整个 crate 的通用立场领域类型可以演进wire 形状必须稳定因此需要显式的镜像类型。SoupCrmContactT的id注释是“Original team-owned contact ID”同时viewed_at是“The viewers latest visit to this record”。这说明同一份联系人记录在不同团队视角下是不同的行viewed_at是 per-viewer 的。通话viewer-relative 的 status 推导SoupCallRecordT的status是item_filters::CallStatus且attended被标注为“为兼容而保留由status ATTENDED派生”。推导逻辑在from_record_for_userfn participant_derived_status(participants: [CallRecordParticipant], user_id: str) - CallStatus { if participants.iter().any(|p| p.user_id user_id) { return CallStatus::Attended; } CallStatus::Unattended }即记录自带status时优先使用否则按“当前用户是否出现在参与者列表”推导。测试覆盖了全部四种组合——记录状态为Missed时不 attended、记录状态为Attended但用户不在参与者中仍为 attended因为记录状态优先、状态缺失时按参与者推导见 call_record/test.rs。结构体注释还声明了被排除的字段room_name、egress_id、transcript——它们对 feed 展示无意义因此不进入 wire 模型。这是“响应模型只包含渲染所需字段”原则的具体体现。日历事件时间表示的双变体#[serde(rename_all camelCase, tag kind)] pub enum SoupCalendarEventTime { Timed { starts_at: DateTimeUtc, ends_at: DateTimeUtc, time_zone: OptionString }, AllDay { start_date: NaiveDate, end_date: NaiveDate }, }注释里有一个非常具体的实现说明字段的 camelCase 是逐变体标注的而不是用rename_all_fields因为 utoipa 会忽略后者导致生成的 OpenAPI 声明 snake_case 而线上实际是 camelCase。这是一个“schema 生成器与 serde 语义不一致”的真实踩坑记录对要接 OpenAPI 的团队有直接参考价值。语义上Timed的ends_at是排他的AllDay的end_date同样是排他日期start_date为包含。ical_uid用于与源日历对账is_read_only表示所选 canonical 源是否只读。Agent 会话与数据库行SoupAgentSessionT的设计目标是“让 coding 与非 coding 会话都能一次渲染无需逐条再查”。因此它内联了运行时与仓库元数据harness、repo_url、repo_branch注释强调这是创建时选择的起始分支不是当前分支、working_branch运行时上报的当前分支、pull_request_url、pull_request_state、pull_request_id、turn_state。status字段的语义被完整定义在注释中首个系统事件到达前为no_messages连接非正常关闭为disconnected否则是最近一次系统事件的 wire 名例如session/end。这种“状态机取值域写进文档注释”的做法避免了消费者猜测字符串。source与visibility直接复用了过滤 DSL 中的类型pub use item_filters::ast::agent_session::{AgentSessionSource, AgentSessionVisibility};这是models_soup依赖item_filters的原因之一——模型与过滤语言共享同一套枚举避免“过滤接受 A 值、响应返回 B 值”的错配。SoupDatabaseRowT则明确了一个权限事实行没有自己的访问控制“access is its databases”访问权限属于其数据库。owner_id注释为“The databases owner, which owns every row in it”created_by是OptionString因为创建者可能已被删除position是表内排序用的分数索引fractional index字符串。特性开关mock 与 schemaCargo.toml 定义了两个 feature[features] mock [] schema [dep:utoipa, item_filters/schema]mock为部分类型附加PartialEq, Eq派生可见于SoupDocumentSubType、SoupContact、SoupLabel等便于测试中直接断言相等。注意它是按类型逐个加的不是全 crate 统一因此不能假设所有SoupItem变体都可比较。schema启用utoipa::ToSchema派生并联动启用item_filters/schema。代码中统一写作#[cfg_attr(feature schema, derive(utoipa::ToSchema))]以及针对特殊字段的#[cfg_attr(feature schema, schema(value_type String))]如owner_id: Owner、MacroUserIdStr。这些覆盖是必要的Owner与MacroUserIdStr在 wire 上是字符串若不覆盖生成的 schema 会暴露内部类型。schema特性同时被soupcrate 用于SoupPropertiesField其axumfeature 下派生ToSchema因此 OpenAPI 的类型一致性是跨 crate 协同的结果。实操为 Soup 新增一种实体类型AGENTS 文档给出的配方是四步结合源码可以把它展开成可执行的清单。这条链路是第 1 步新建src/kind.rs。定义SoupXxxT ()遵循三条约定结构体上加#[serde(rename_all camelCase)]以及#[cfg_attr(feature schema, derive(utoipa::ToSchema))]。带属性的实体保留#[serde(flatten)] pub extra: T不支持的实体的extra可以直接省略如SoupForeignEntity。可选字段用#[serde(skip_serializing_if Option::is_none)]让 JSON 更紧凑但只有需要“缺省即 false”语义的布尔字段才加#[serde(default)]参考is_participant与source。第 2 步在lib.rs注册模块并在pub mod上方写一行文档注释——#![deny(missing_docs)]会强制这一步。第 3 步接入item.rs的统一条目。这一步是编译期强制的共五处SoupItem枚举新增变体entity()新增EntityType::Xxx.with_entity_string(...)分支updated_at()新增分支决定 frecency 回退排序键cursor_timestamp()新增四个SimpleSortMethod分支或像Call、EmailThread那样合并为通配_分支to_entity_reference()新增分支若该实体不支持属性写None并附注释说明原因map_extra()新增完整解构分支若变体带TIdentify::id()新增分支。漏掉任何一处都会编译失败除to_entity_reference外因为它是显式match同样会失败。这正是枚举 穷尽匹配的价值。第 4 步向上游接线。依次是soupfeed 查询、graphql_soupGraphQL 暴露。后者需要新增一个GraphqlSoupXxx对象并在GraphqlSoupEntity枚举中加入变体可参照 objects.rs 的现有 15 个变体含已废弃的Reminder注释标注 “never constructed”。一个容易遗漏的细节来自soupcrate 的文档GraphQL 层的枚举与SoupItem枚举不是一一对应的——SoupItem::ChannelThread在 GraphQL 层叫ChannelMessage。命名差异是有意的wire 语义统一到 canonical 概念新增类型时不要机械照抄 Rust 变体名。校验与测试文档给出的检查命令是cargo test -p models_soup并特别注明SQLX_OFFLINE不要设置。原因在于该 crate 的测试包含依赖数据库 schema 信息的路径这与soupcrate 的检查要求相互印证——soup需要cargo test -p soup --features outbound加本地 MacroDB且在 schema/query 变更后执行nix develop --command just prepare_db见 crates/soup/AGENTS.md。models_soup的测试覆盖了三类风险测试文件覆盖点item/test.rs序列化形状、map_extra扁平化comms/test.rsis_participant位置与向后兼容反序列化call_record/test.rsviewer-relative 状态推导、三种排序下的 recency 一致性其中assert_call_recency是最有借鉴价值的模式它同时断言updated_at()与sort_on()的结果把“两个应该一致的时间来源”绑在同一个测试里。新增实体类型时建议照此编写针对cursor_timestamp各分支的测试尤其是存在特殊语义的变体无viewed_at、非updated_at排序键等。边界规则为什么这些代码不该放在这里模型的职责边界不只是组织代码也是避免循环依赖的手段。三条判断规则可直接落地“这个实体怎么创建/编辑”不属于本 crate。频道、文档、initiative 的写入逻辑在各自领域 cratemodels_soup只定义它们的 soup 展示形状。“怎么查”不属于本 crate。跨实体过滤、排序、分组、排除、分页与 Postgres 查询都在soupper-entity 缓存投影在soup_filter_projectionSoup 补丁的实时分发在soup_realtime。“过滤语言”不属于本 crate。item_filters/soup_filter_projection拥有 DSLmodels_soup只在必要时复用其中的枚举如CallStatus、AgentSessionSource以保持过滤值与响应值同源。反过来本 crate 被ai_tools、complete_graph、databases_sql、graphql_initiative、graphql_soup、models_search、search_service、skills、soup、soup_filter_projection、work_feed使用。这意味着任何一个 wire 字段改名影响面会同时波及 GraphQL API、AI 工具输出与搜索索引投影——因此“wire 形状必须稳定”不是风格偏好而是本 crate 的硬约束。修改字段前应先确认下游是否需要同步例如soup的SoupPropertiesField、GraphQL 的对象映射。小结models_soup看起来只是“一堆响应结构体”实际上它用三件事把分散的实体收束成一个可排序、可分页、可带属性的统一 feed一个外部标记的枚举SoupItemT用tag/data提供稳定的 JSON 形状用泛型T提供可选的属性挂载点用map_extra保证扩展字段被正确扁平化。一套排序契约updated_at()、cursor_timestamp()、Identify、SortOn四者必须与 SQL 侧表达式严格一致邮件线程、日历事件、通话记录、数据库行都是有意的例外且每一处例外都在源码注释中写明了原因。一组实体专属的建模取舍文档子类型把任务属性升进类型系统CRM 类型刻意镜像以稳定 wire 形状通话状态是 viewer-relative 推导日历时间区分 Timed 与 AllDay 并规避 utoipa 的rename_all_fields缺陷。新增实体类型时只要按src/kind.rs→lib.rs→item.rs六处分支 →soup→graphql_soup的顺序推进并以cargo test -p models_soup不设SQLX_OFFLINE作为验收就能把改动限定在模型层不触碰查询与权限逻辑。赞分享后端前端协同办公即时通讯企业应用CRMAI Agent人工智能【免费下载链接】macroMacro is a unified workspace for teams: email, chat, docs, tasks, agents, calls, and CRM — -linked together with shared AI memory.项目地址https://gitcode.com/GitHub_Trending/macro3/macro点击查看免费下载相关推荐Macro 只读问题追踪器导入契约import_tracker 的领域模型、分页与限流实现解析Macro 只读问题追踪器导入契约import_tracker 的领域模型、分页与限流实现解析 import_tracker 是 Macro 中负责“从 Li后端前端协同办公即时通讯企业应用CRMAI Agent人工智能深入解析 TanStack Table 的 Table_RowModels 类型行模型管道的完整类型契约深入解析 TanStack Table 的 Table_RowModels 类型行模型管道的完整类型契约 Table_RowModelsTFeatures,前端UI组件UniMate模型如何转换到MLXPyTorch → unimate-uniml3d-f60-v3-bf16的bfloat16转换全过程笔记UniMate模型如何转换到MLXPyTorch → unimate uniml3d f60 v3 bf16的bfloat16转换全过程笔记 UniMate上一篇OpenMetadata Java Code Reviewer Agent 实战指南以 Kafka 级标准审查后端代码下一篇DiceDB ZRANGE 命令详解有序集合区间查询的语法、语义与底层实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
